Menu
▾
▴
|
From: antst <an...@ma...> - 2006-07-11 03:03:27
Attachments:
lcd4linux-g15.patch
|
Hi! There is a patch for G15 driver (CVS) which is 1) fix three bugs in the code which were reason for segfaults(arrays boundaries) 2) add support for extra keys on keyboard (G1-G18, M1-M3,MR and 5 extra keys above multimedia keys, I call them L0-L4). It requires "uinput" to be switched on in kernel (if you don't want support for keys - just comment out "UInput" parameter in config file). BTW, "lcd4linux.conf.sample" is also patched to include device definition for G15. With this patch keys produce some keycodes, which later can be used. For example, in X you can see keycodes with "xev" and bind them with "xbindkeys", like any other keys. Or use "xmodmap". Also here is some (ugly?) patch for plugin_exec, which force all child processes to be killed when main process is terminated. Anton. |
|
From: Michael R. <re...@eu...> - 2006-07-13 05:29:10
|
Hi Anton, > There is a patch for G15 driver (CVS) which is Thanks a lot for your contribution! Patch has been applied and checked in. > 1) fix three bugs in the code which were reason for segfaults(arrays > boundaries) Great! Benjamin, does this fix your problems? > 2) add support for extra keys on keyboard (G1-G18, M1-M3,MR and 5 extra > keys above multimedia keys, I call them L0-L4). It requires "uinput" to > be switched on in kernel (if you don't want support for keys - just > comment out "UInput" parameter in config file). BTW, > "lcd4linux.conf.sample" is also patched to include device definition for > G15. Now this sounds like a great idea! Q: are there any prerequisites for using uinput? Kernel version? We should add some checks to configure, I'm afraid.... I don't know anything about the linux's uinput layer, but would it be possible to use this stuff for all other displays with keys, too? There's already a generic key handler in lcd4linux, which does nothing at the moment but emit a debug message "key xy pressed". Should be easy to integrate the passing to uinput.... on the other hand, is it possible to "get" generic keypresses from uinput, too? this way, lcd4linux would benefit from other keys (probably some unused keys from your keyboard, joystick, ..) Any input would be greatly appreciated! > Also here is some (ugly?) patch for plugin_exec, which force all child > processes to be killed when main process is terminated. Thanks again. I know of this problem for months, but couldn't find the time to hunt it. I moved your signal() to a seperate function 'thread_destroy()', which is at least a bit less ugly :-) Thanks again, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Jay C. <jay...@ya...> - 2006-07-13 07:34:37
|
Glad to see the seg faults are fixed and the input stuff is a nice supprise as far as i know the uinput framework is used for insernting keypresses, if you want to read them then you read from the /dev/event interfaces, each one corrisponding to a specific device. using this means that you could prot lcd screen buttons to do key presses which can then be used by any other program and then have a module that works and responds on key presses basicaly you could use any button to change the LCD screen content the only problem i can see is how you play nice with the rest of the system. another usless ramble by: Jay Coles jay...@ya... aka Da_Blitz __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: antst <an...@ma...> - 2006-07-14 10:03:26
|
Jay Coles wrote: > Glad to see the seg faults are fixed and the input > stuff is a nice supprise > > as far as i know the uinput framework is used for > insernting keypresses, if you want to read them then > you read from the /dev/event interfaces, each one > corrisponding to a specific device. > > using this means that you could prot lcd screen > buttons to do key presses which can then be used by > any other program and then have a module that works > and responds on key presses > > basicaly you could use any button to change the LCD > screen content > > the only problem i can see is how you play nice with > the rest of the system. > Hm...I don't see the way, how it is going to work, when eventX is already used by some program (X server, for example) Anton |
|
From: Jay C. <jay...@ya...> - 2006-07-14 12:14:54
|
Hence the: > the only problem i can see is how you play nice with > the rest of the system. so i guess you can get keypress from X, if you want command line support you will have to play around with the keymap files __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: antst <an...@ma...> - 2006-07-14 09:56:26
|
> Now this sounds like a great idea! > > Q: are there any prerequisites for using uinput? Kernel version? We > should add some checks to configure, I'm afraid.... > I think it is standard in 2.6 kernels. It just should be switched on. (I think on most distros it is default option) "CONFIG_INPUT_UINPUT=y" in ".config" > I don't know anything about the linux's uinput layer, but would it be > possible to use this stuff for all other displays with keys, too? > There's already a generic key handler in lcd4linux, which does nothing > at the moment but emit a debug message "key xy pressed". Should be easy > to integrate the passing to uinput.... > Yes, this can be done, very easy. I'll try to write patch at weekend. > on the other hand, is it possible to "get" generic keypresses from > uinput, too? this way, lcd4linux would benefit from other keys (probably > some unused keys from your keyboard, joystick, ..) > Hm...don't know does it work in back direction :) never thought :) > Thanks again. I know of this problem for months, but couldn't find the > time to hunt it. I moved your signal() to a seperate function > 'thread_destroy()', which is at least a bit less ugly :-) > :)) Anton. |
