g15tools-devel Mailing List for g15tools

Heya, anyone of you still alive :p?

I was wondering if you could grant me permission to be able to modify & 
close tickets.
I just took care of 
https://sourceforge.net/tracker/?func=detail&aid=3088409&group_id=167869&atid=844656 
but I did not have the access to actually close it..


// Daniel ("steelside")

Heya, anyone of you still alive :p?

I was wondering if you could grant me permission to be able to modify & 
close tickets.
I just took care of 
https://sourceforge.net/tracker/?func=detail&aid=3088409&group_id=167869&atid=844656 
but I did not have the access to actually close it..


// Daniel ("steelside")

Hi Cate,

>> I've been thinking about the g15tools and I was wondering whether anyone
>> has any thoughts about building the G15 driver into the kernel instead
>> of as a standalone userspace daemon.
>>
>> I think it would quite handy if the kernel recognised the extra keys out
>> of the box, without needing to load any programs first.
> 
> I don't know if this is a good idea.
> Usually the "new keys" are put in some configuration files
> (i.e. "loadkeys" command). I don't know if G15 is different
> on key codes: I don't use extra keys on virtual terminal
> (or via ssh).
> 
> The kernel will give key only to console and virtual terminal,
> so anyway you need also a driver for xorg. (actually there is
> already a driver in xorg, but it requires g15daemon).

Actually I wasn't thinking of making the keys available to userspace
(although being able to press G1-G6 to switch virtual console would be
kinda cool), I was thinking of simply "activating" the extra G-keys, in
exactly the same way that g15daemon does.

At the moment as soon as the kernel loads, the G-keys are disabled (G1
generates the scancode for F1, G2 generates the scancode for F2, etc.)
As soon as you load G15daemon, the G-keys are activated and begin
generating unique scancodes, but it's then up to a program to do
something with those scancodes.

What I was proposing was to activate the G-keys in-kernel, so g15daemon
doesn't need to be running to use the extra keys.  You would still need
to configure your programs to recognise the new scancodes (as you must
do anyway) but I thought it might be "cleaner" not requiring a userspace
program to be running all the time for this.

Cheers,
Adam.

Adam Nielsen wrote:
> Hi all,
> 
> I've been thinking about the g15tools and I was wondering whether anyone
> has any thoughts about building the G15 driver into the kernel instead
> of as a standalone userspace daemon.
> 
> I think it would quite handy if the kernel recognised the extra keys out
> of the box, without needing to load any programs first.
> 
> This would also mean g15macro could be extended/renamed to provide macro
> functionality for any keyboard, although you'd still probably want to
> keep this functionality separate to avoid clogging up the kernel.
> 
> Does anyone have any comments on whether this is a good or a bad idea?
> Never having written any sort of kernel drivers before I'm quite keen to
> start something like this, but I don't want to tread on anyone's toes!

I don't know if this is a good idea.
Usually the "new keys" are put in some configuration files
(i.e. "loadkeys" command). I don't know if G15 is different
on key codes: I don't use extra keys on virtual terminal
(or via ssh).

The kernel will give key only to console and virtual terminal,
so anyway you need also a driver for xorg. (actually there is
already a driver in xorg, but it requires g15daemon).

[ application normally read "characters" (not keys), so you need
some terminal sequence codes and support for your TERM.
X11 instead read keys (so a new driver), and it can use other
means to send keycodes to programs. ]

ciao
	cate

Hi all,

I've been thinking about the g15tools and I was wondering whether anyone
has any thoughts about building the G15 driver into the kernel instead
of as a standalone userspace daemon.

I think it would quite handy if the kernel recognised the extra keys out
of the box, without needing to load any programs first.

This would also mean g15macro could be extended/renamed to provide macro
functionality for any keyboard, although you'd still probably want to
keep this functionality separate to avoid clogging up the kernel.

Does anyone have any comments on whether this is a good or a bad idea?
Never having written any sort of kernel drivers before I'm quite keen to
start something like this, but I don't want to tread on anyone's toes!

Cheers,
Adam.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just saw this article.  http://www.dvhardware.net/article20804.html
It looks like we'll have another one to support now.  Looks like the
only non-cosmetic change is that there are only 6 G keys now.  Hopefully
the LCD and everything else is still the same.  Logitech.com doesn't
seem to say when it will be available, but the old one isn't showing
anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7cpTSdAxC41Y09ERAmk1AKCXg89r/2zUvOLbeDkMvW3HeI1xrgCdGXf5
9znDMlp99FVV72Y8NIMZNP0=
=Hs3z
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giacomo A. Catenazzi wrote:
> Anthony J. Mirabella wrote:
>> Giacomo Catenazzi wrote:
>>> In Debian I put also explicit more lines with the yacc/lex parser
>>> interface.  I don't know exactly how it work, but I think there
>>> are better way (Makefile.am) to automatic include a (new
>>> automatic generated) header (?).
>> Not sure I understand what you mean here.
> 
> Sorry.
> 
> These symbols are used in g15composer.c :
> extern int yylex_init (yyscan_t* scanner);
> extern void yyset_in  (FILE * in_str ,yyscan_t yyscanner );
> extern int yyparse (void *YYPARSE_PARAM);
> extern FILE *yyget_in (yyscan_t yyscanner );
> extern int yylex (YYSTYPE * yylval_param ,yyscan_t yyscanner);
> extern int yylex_destroy (yyscan_t yyscanner );
> 
> I think a .h file generated by lex should be included.
> I don't really know exactly how lex/yacc works, so
> I've no idea

Right.  Those are included in the g15composer.tab.[ch] files that are
generated from g15composer.lex.c (generated from g15composer.l) and
g15composer.y.  g15composer.[ly] are included in the distfile and the
Makefile generates g15composer.lex.c and g15composer.tab.[ch] with lex
and yacc before compiling g15comopser.c.  They're then all statically
linked into g15composer.

>>> configure.in
>>> you should check FreeType package with:
>>> # AC_CHECK_FT2([MINIMUM-VERSION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
>>> # Test for FreeType 2, and define FT2_CFLAGS and FT2_LIBS.
>>> # MINIMUM-VERSION is what libtool reports; the default is `7.0.1' (this is
>>> # FreeType 2.0.4).
>>> the header check it is not enough because FreeType requires
>>> "pkg-config --cflags freetype2"
>> I'll check this out.  I had been using the check on libg15render's
>> g15r_ttfLoad because we need to ensure that libg15render also has TTF
>> support.  I can probably combine the two in some way that should do
>> what's needed.  Do you want me to put out a new release with these changes?
> 
> I think there is no need for FreeType headers, so forget my comments.
> The composer will not link to FreeType (in a direct way).

Ok, I'll still look at using this in libg15render, as it's not really
checking for the existence of freetype other than with ft2build.h.
g15composer also needs the include paths, so I might as well add it
there too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7ahUSdAxC41Y09ERArD7AKCpSIqiUTfU13iksH3YEXWMLkiLcACgtCRa
Ec9CJlEzLajPXSzSb9MABjk=
=wpDp
-----END PGP SIGNATURE-----

Anthony J. Mirabella wrote:
> Giacomo Catenazzi wrote:
>> In Debian I put also explicit more lines with the yacc/lex parser
>> interface.  I don't know exactly how it work, but I think there
>> are better way (Makefile.am) to automatic include a (new
>> automatic generated) header (?).
> 
> Not sure I understand what you mean here.

Sorry.

These symbols are used in g15composer.c :
extern int yylex_init (yyscan_t* scanner);
extern void yyset_in  (FILE * in_str ,yyscan_t yyscanner );
extern int yyparse (void *YYPARSE_PARAM);
extern FILE *yyget_in (yyscan_t yyscanner );
extern int yylex (YYSTYPE * yylval_param ,yyscan_t yyscanner);
extern int yylex_destroy (yyscan_t yyscanner );

I think a .h file generated by lex should be included.
I don't really know exactly how lex/yacc works, so
I've no idea


> 
>> configure.in
>> you should check FreeType package with:
> 
>> # AC_CHECK_FT2([MINIMUM-VERSION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
>> # Test for FreeType 2, and define FT2_CFLAGS and FT2_LIBS.
>> # MINIMUM-VERSION is what libtool reports; the default is `7.0.1' (this is
>> # FreeType 2.0.4).
> 
>> the header check it is not enough because FreeType requires
>> "pkg-config --cflags freetype2"
> 
> I'll check this out.  I had been using the check on libg15render's
> g15r_ttfLoad because we need to ensure that libg15render also has TTF
> support.  I can probably combine the two in some way that should do
> what's needed.  Do you want me to put out a new release with these changes?

I think there is no need for FreeType headers, so forget my comments.
The composer will not link to FreeType (in a direct way).

ciao
	cate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giacomo Catenazzi wrote:
> Hello,
> 
> Now I'm into g15composer check, and I've some changes:
> 
> Missing includes:
> 
> --- g15composer-3.1.orig/g15composer.c
> +++ g15composer-3.1/g15composer.c
> @@ -18,6 +18,7 @@
> 
>  #include <stdio.h>
>  #include <string.h>
> +#include <stdlib.h>
>  #include <sys/types.h>
>  #include <sys/socket.h>
>  #include <sys/stat.h>
> @@ -25,6 +26,7 @@
>  #include <errno.h>
>  #include <pwd.h>
>  #include <fcntl.h>
> +#include <unistd.h>
>  #include <libgen.h>
>  #include <libg15.h>
>  #include <libg15render.h>

Done, thanks.

> In Debian I put also explicit more lines with the yacc/lex parser
> interface.  I don't know exactly how it work, but I think there
> are better way (Makefile.am) to automatic include a (new
> automatic generated) header (?).

Not sure I understand what you mean here.

> configure.in
> you should check FreeType package with:
> 
> # AC_CHECK_FT2([MINIMUM-VERSION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
> # Test for FreeType 2, and define FT2_CFLAGS and FT2_LIBS.
> # MINIMUM-VERSION is what libtool reports; the default is `7.0.1' (this is
> # FreeType 2.0.4).
> 
> the header check it is not enough because FreeType requires
> "pkg-config --cflags freetype2"

I'll check this out.  I had been using the check on libg15render's
g15r_ttfLoad because we need to ensure that libg15render also has TTF
support.  I can probably combine the two in some way that should do
what's needed.  Do you want me to put out a new release with these changes?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7aPcSdAxC41Y09ERAtPDAKDXM0RzhnyplCRcYlY9pLmLFAL7ogCeI/hN
X+nOPjzmM6LDn72JN9zvEgA=
=vic1
-----END PGP SIGNATURE-----

Hello,

Now I'm into g15composer check, and I've some changes:

Missing includes:

--- g15composer-3.1.orig/g15composer.c
+++ g15composer-3.1/g15composer.c
@@ -18,6 +18,7 @@

 #include <stdio.h>
 #include <string.h>
+#include <stdlib.h>
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/stat.h>
@@ -25,6 +26,7 @@
 #include <errno.h>
 #include <pwd.h>
 #include <fcntl.h>
+#include <unistd.h>
 #include <libgen.h>
 #include <libg15.h>
 #include <libg15render.h>


In Debian I put also explicit more lines with the yacc/lex parser
interface.  I don't know exactly how it work, but I think there
are better way (Makefile.am) to automatic include a (new
automatic generated) header (?).


configure.in
you should check FreeType package with:

# AC_CHECK_FT2([MINIMUM-VERSION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
# Test for FreeType 2, and define FT2_CFLAGS and FT2_LIBS.
# MINIMUM-VERSION is what libtool reports; the default is `7.0.1' (this is
# FreeType 2.0.4).

the header check it is not enough because FreeType requires
"pkg-config --cflags freetype2"

ciao
	cate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giacomo Catenazzi wrote:
> Anthony J. Mirabella wrote:
>> Giacomo Catenazzi wrote:
>>> Hello,
>>> The file libg15render.h includes "config.h", which
>>> is wrong when it is used in "/usr/include".
>>> For debian I hardcoded the TTF_SUPPORT definition
>>> (Debian will have only a single library), but
>>> for the upstream sources I don't really know
>>> how you should proceed.
>>> Maybe you need an install hook that
>>> include "config.h" into the sources,
>>> but really I don't have any good solution.
>>> ciao
>>> 	cate
>> I had originally made TTF_SUPPORT optional so as to not add to the
>> dependencies, but it seems that it causes more trouble than its worth.
>> Would anyone object to requiring freetype2 in the next major release?
> 
> Considering the target of our user, I find no big problem to add
> inconditionately the TTF_SUPPORT.
> I don't think Debian user will ask for a second version without
> TTF dependencies.
> 
> Alternately, I propose:
> the header file will include uncondisionally TTF support, but
> the libraries has an alternate version: without TTF support
> the function will do nothing.  Eventually you can modify
> the function definition: returning an integer instead of void,
> and return 0 on unsupported function.
> In this manner actual program will still work.
> 
> Removing configuration dependencies on a "struct" will enormely
> simplify updated, recompilation (and remove suble crashes)

The problem I had with always including TTF support in the header is
that any program using the header then has to include the truetype
headers, defeating the purpose of making it optional.  I tend to think
that it's better just to require it.  It seems that most distros ship
with truetype2, so that shouldn't be much of a stumbling block.

>> Speaking of which, I'm planning on changing the libg15render API in the
>> next major release.  I'll handle updating all of the other programs in
>> the project that use it, but does anyone have any preference regarding
>> how that's done?  Should I do a version check and try to keep them
>> compatible with both API versions?  Should everything get a major
>> version bump and only use the new API?
> 
> I've no preferences, or better:
> I don't like the "try" of the first proposal.
> If you keep it compatible (but eventually extended), it should
> be nearly 100% compatible.
> In case of the second proposal, please check that SONAME has
> a new version (so that two libary version can be installed
> in paralled for transition).
> 
> IMHO this is really your choice (is actual API broken?
> will the new API simplify the code (library and/or
> user of library?)

Yeah, I tend to think that maintaining code for two different APIs will
only be a maintenance headache that will undoubtedly lead to bugs.  It's
not quite like g15daemon 1.2/1.9 where there was really only one
significant external change.  I'm going to try to keep the API as close
as possible, but the g15canvas struct will be replaced by another struct
that contains more info and pointers to the get/set_pixel functions
which should make it easier to support other LCD types and eliminate the
need for clients to do their own memory management for the canvas.  Even
if the function syntax remains essentially the same, some changes will
need to be made to clients.  Thankfully, the g15composer syntax should
remain the same, so any scripts using that won't need modification.

I've updated the libtool version in the new branch, I'll make sure the
SONAME is updated as well.  Should it be something like libg15render2?
Would I then reset the libtool version to 0:0:0?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7Z9WSdAxC41Y09ERAhgDAKC/hcof5tgZ/jiEbtAczLd7m6WEAQCgiHph
PAHFplU+ewS+/bORXhCJSsQ=
=hlmz
-----END PGP SIGNATURE-----

Anthony J. Mirabella wrote:
> Giacomo Catenazzi wrote:
>> Hello,
> 
>> The file libg15render.h includes "config.h", which
>> is wrong when it is used in "/usr/include".
> 
>> For debian I hardcoded the TTF_SUPPORT definition
>> (Debian will have only a single library), but
>> for the upstream sources I don't really know
>> how you should proceed.
>> Maybe you need an install hook that
>> include "config.h" into the sources,
>> but really I don't have any good solution.
> 
>> ciao
>> 	cate
> 
> I had originally made TTF_SUPPORT optional so as to not add to the
> dependencies, but it seems that it causes more trouble than its worth.
> Would anyone object to requiring freetype2 in the next major release?

Considering the target of our user, I find no big problem to add
inconditionately the TTF_SUPPORT.
I don't think Debian user will ask for a second version without
TTF dependencies.

Alternately, I propose:
the header file will include uncondisionally TTF support, but
the libraries has an alternate version: without TTF support
the function will do nothing.  Eventually you can modify
the function definition: returning an integer instead of void,
and return 0 on unsupported function.
In this manner actual program will still work.

Removing configuration dependencies on a "struct" will enormely
simplify updated, recompilation (and remove suble crashes)


> Speaking of which, I'm planning on changing the libg15render API in the
> next major release.  I'll handle updating all of the other programs in
> the project that use it, but does anyone have any preference regarding
> how that's done?  Should I do a version check and try to keep them
> compatible with both API versions?  Should everything get a major
> version bump and only use the new API?

I've no preferences, or better:
I don't like the "try" of the first proposal.
If you keep it compatible (but eventually extended), it should
be nearly 100% compatible.
In case of the second proposal, please check that SONAME has
a new version (so that two libary version can be installed
in paralled for transition).

IMHO this is really your choice (is actual API broken?
will the new API simplify the code (library and/or
user of library?)

ciao
	cate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giacomo Catenazzi wrote:
> Hello,
> 
> The file libg15render.h includes "config.h", which
> is wrong when it is used in "/usr/include".
> 
> For debian I hardcoded the TTF_SUPPORT definition
> (Debian will have only a single library), but
> for the upstream sources I don't really know
> how you should proceed.
> Maybe you need an install hook that
> include "config.h" into the sources,
> but really I don't have any good solution.
> 
> ciao
> 	cate

I had originally made TTF_SUPPORT optional so as to not add to the
dependencies, but it seems that it causes more trouble than its worth.
Would anyone object to requiring freetype2 in the next major release?

Speaking of which, I'm planning on changing the libg15render API in the
next major release.  I'll handle updating all of the other programs in
the project that use it, but does anyone have any preference regarding
how that's done?  Should I do a version check and try to keep them
compatible with both API versions?  Should everything get a major
version bump and only use the new API?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7XXsSdAxC41Y09ERAp/0AKDocQoQexPrHK/dg338x92M+QtdPQCfTMvy
NqxJFK9MascfSTNIGvgZxK4=
=0YsM
-----END PGP SIGNATURE-----

Hello,

The file libg15render.h includes "config.h", which
is wrong when it is used in "/usr/include".

For debian I hardcoded the TTF_SUPPORT definition
(Debian will have only a single library), but
for the upstream sources I don't really know
how you should proceed.
Maybe you need an install hook that
include "config.h" into the sources,
but really I don't have any good solution.

ciao
	cate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been trying to get the OS X port working and I'm not having any
luck.  libg15 fails to claim the interface when starting g15daemon and
then things go bad from there.  After a short time the keyboard stops
working and then the system hangs on reboot until I boot from the
install CD and remove the libusbshield.kext.  I can't quite tell if the
kext is malformed or if it's something that libg15 is doing wrong.
Anyone have any ideas?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5cSZSdAxC41Y09ERAk1aAKCu1zBalH4Yf/qkGJermIb68IvoZwCfW4nH
pyjvXg3o8/J1ietOj2pt7uU=
=NYfy
-----END PGP SIGNATURE-----

Hello,

finally the first batch of g15 packages are included in debian.

I've just uploaded the last wip version of g15daemon, but
I've still have a patch:

- add a missing NAME section in man page g15daemon_client_devel.3
  (used for apropos,...)
- use volatile for data that are changed in signals
- don't loop araound a sleep(), but pause() waiting for a signal.

In next days I'll update the packages, and pack the missing packages.

I've only a small request: could you distribute in next releases also
a .tar.gz file?

ciao
	cate

FYI about Debian packages:
http://packages.qa.debian.org/g/g15daemon.html
http://packages.qa.debian.org/libg/libg15.html
http://packages.qa.debian.org/libg/libg15render.html

Hello

I attach some fixes to g15daemon.

I'm having some problem with svn, so
I'm not sure I'm using the last version.
How do I checkout the last version?

Anyway in attachment:
- some compiler fixes,
- moving shared variables into g15d.h
  (shared between files in g15daemon,
  not for plugins).
  "extern" on .c files can cause difficult to debug bugs
  if one don't change the type on all files.
- use volatile for "leaving". It is the right way for
  variables set in signal handler: it avoid some
  compiler optimitazion / cache incoherencies on some
  archs.

ciao
	cate

Hello,

I'm trying to pack the libg15tools into Debian.

In libg15render-1.2 I've found some bugs,
the attached patch will correct it.

ciao
	cate

Hello

I would like to package g15tools and g15daemon for Debian.
Is it OK for you?

Note that this is also a fast track to enter on ubuntu.


I see that you have already done the debian directories,
but I need to completely ignore it (but the first time
I'll check and use some of your texts and code).
IMHO the packing information should not be in the upstream
version because it would be very difficult to maintain.
[ but eventually as additional distribution source format]

ciao
	cate

Hello,

I have just tried out this library of code and have run into a problem where
the initLibG15 fails.
The error message is as follows:

Found g15, trying to open it
Debug:
Error setting the configuration, this is fatal
zsh: segmentation fault  ./test-g15

I am running on a 64 bit chip with a 64 bit fedora distro (6). Any ideas on
what might be the problem
would be much appreciated.

Cheers,
Alex

-- 
Alex Waterman
imn...@gm...
Ale...@gm...
Support or create OpenSource

The word 'politics' is derived from the word 'poly', meaning 'many', and the
word 'tics', meaning 'blood sucking parasites'.