# On-keyboard LCD support. Details within.

## Nondysjunction

The logitech G15 keyboard is an interesting piece of technology. It features a volume knob, multimedia keys, a backlit keyboard, and configurable macro keys, not to mention an LCD display built right into the keyboard.

 I have got mostly everything working, except the LCD, and I was wondering if the kernel-level USB-based LCD support might work for this. On my system, the support is embodied by the kernel module usblcd. I am running on 2.6.14-gentoo-r3 currently. 

If anyone had any resources related to small-scale LCDs under Linux or the usblcd kernel support, I would greatly appreciate any input.

Edit: I do realize that is not the purpose of the usblcd kernel support. However; maybe this may work?

Thank you for your time, cheers.  :Smile: 

----------

## porsche08

I'm wondering if you were able to get macros working.  I just bought one of these, but haven't hooked it up to my linux box yet.  All I'm really interested in is using the G keys speed up programming a bit.  For example, hitting G1 drops an if / else statement into my code.

Ryan

----------

## nosenseofhumor1

i got one too, and its pretty sweet but drivers make a world of difference.

i have been doing some research, and i have found some interesting tools. i am not a device programmer though, so instead of taking a crack at this myself i would like to share what i have found with you folks and see if anybody makes ground on this freakin thing. 

first of all, its a good idea to get a windows box and install USB snoopy on it http://www.wingmanteam.com/usbsnoopy/

using USB snoopy you can listen to the transmission between the bus and device. Filter through the nonsense and find sent messages that seem to occur during image changes on the LCD. 

next use the usb skel driver (drivers/usb/usb-skeleton.c) in the kernel source tree for a template. i dont know how this is accomplished, but the fops and minor variables in the declaration of the driver can be used to register your new driver with a TTY subsystem (!!). 

of course then you have to write in functions for register/deregister and whatever other standard usb driver requirements are out there. but if you can register this thing with a tty subsystem, talking to the LCD in userspace would be cake! 

...that doesnt help at all does it?

----------

## nomenquis

Hi,

I started writing a driver for this one. It seems to work pretty well.

http://www.waug.at/g15lcd/

Basically you have to patch your kernel a little bit (nothing dangerous though) and then compile a userspace app with libusb which will print text to the screen. The code for drawing pixels is already in there, so just be creative  :Smile: 

Also I'll put a more advanced (smaller / better font etc) version up soon.

Oh, and i hope no one minds the spelling, this keyboard is strange to type on  :Wink: 

kind regards

----------

## nosenseofhumor1

nice work! im a little confused about something though; in one of the images on your page i can barely make out that you are pipeing "hello world" into a file in /var... did i miss something?

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> nice work! im a little confused about something though; in one of the images on your page i can barely make out that you are pipeing "hello world" into a file in /var... did i miss something?

 

Ok, this little program just reads 5 lines from stdin and displays them, in an endless loop, as soon as it gets another 5 lines it will display these instead.

So I wanted to simply pipe the output from a script which generates the actual data I want to diplay into g15lcd.

The problem is if you

mknod foo p

cat foo | g15lcd  &

echo "foobar" > foo

then stdin of g15lcd will get an eof as soon as echo "foobar" terminates.

-> g15lcd will stop reading

now you could either always pipe into a new g15lcd process (costly since the usb device opening will be done all the time) or, and thats what i did, create a second process which will simply read data from fifo A and write to stdout. If it gets an EOF from fifo A it will simply reopen it again. So, my setup is the following

a pipe in /var/run/g15lcd called g15_lcd_pipe, and another one called g15_lcd_pipe_internal

then I'm running

fifo_redir_helper g15_lcd_pipe > g15_lcd_pipe_internal &

cat g15_lcd_pipe_internal | g15lcd &

thus I can simply cat / echo data into g15_lcd_pipe and everything works.

(And my two pipes are in /var/run/g15lcd/, thats what you saw in the terminal)

For instance the last screenshot on the page is from a simple script (php, run by cron every minute) which will echo 5 lines into g15_lcd_pipe (the stock quotes which i get from yahoo).

kind regards

----------

## nosenseofhumor1

wow, good trick! i have a few more questions though; are you looping the "display stdin" because the LCD requires that you are constantly sending data to it or it will clear the display, or because there wasnt a better way to watch it for changes and the loop's load is rather insignificant?

also,

 *Quote:*   

> 
> 
> then I'm running 
> 
> fifo_redir_helper g15_lcd_pipe > g15_lcd_pipe_internal & 
> ...

 

when? once? after you send to g15_lcd_pipe? is this also in an endless loop?

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> wow, good trick! i have a few more questions though; are you looping the "display stdin" because the LCD requires that you are constantly sending data to it or it will clear the display, or because there wasnt a better way to watch it for changes and the loop's load is rather insignificant? 

 

No, the LCD stores the data and I only have to update it when it changes. So, I'm not constantly looping but simply wait for another 5 lines of input. Until I get these the program does nothing. So, there is _zero_ load due to this.

 *nosenseofhumor1 wrote:*   

> 
> 
>  *Quote:*   
> 
> then I'm running 
> ...

 

These two processes (fifo_redir_helper and g15lcd) will run forever untill you kill them. But non of these does any sort of polling. Until you send something to g15_lcd_pipe nothing happens. What will happen if you echo somthing into g15lcdpipe is that fifo_redir_helper will read the input until it gets an EOF, then it will print it out to stdout (which will write into g15_lcd_pipe_internal) and then it will reopen g15_lcd_pipe. 

Then g15lcd will read from g15_lcd_pipe_internal (but it wont get and eof) and print that to the lcd

kind regards

----------

## nomenquis

Ok, I've updated the page (http://www.waug.at/g15lcd/)  with a newer version.

You now don't need any fifo helpers anymore, the program does it itself. Also you can have three different fonts now. As another bonus the ability to directly draw pictures (simply set active / inactive pixels) was added.

kind regards

----------

## nosenseofhumor1

ooooooooooo  :Smile: 

hey, youre one hell of a programmer! thanks, you are a valuable asset to the community!

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> ooooooooooo 
> 
> hey, youre one hell of a programmer! thanks, you are a valuable asset to the community!

 

 :Smile: 

Thanks a lot.

Did you actually try it? I'd really like some feedback if this thing works for someone besides me.

kind regards

----------

## nosenseofhumor1

not yet, since im going to have to patch my kernel i wanted to make a few tweaks on my menuconfig first... in the next couple of days i should have it going  :Smile: 

----------

## holycow

Man, am I glad I found this thread. You've done some outstanding work.

I got my g15 keyboard a couple days ago and have been looking for ways to use it's capability under Linux. Your patch and utility open the door for using the lcd.

I patched my 2.6.15 kernel and got it going without any issues. The g15lcd util compiled fine and I was putting text on the lcd in no time at all. I like the image support you've added too.

I will say that having to format the text lines to a single line of quoted text is a bit awkward, but works. Converting images to the "0" and "1" format is also a bit awkward, but doable. I'll have to write a conversion utility for this.

Now, if only the G-keys worked...

If you haven't yet, check out http://phyreskull.ithium.net/g15wiki/wiki/Main_Page. Some good work going on there too.

Thanks!

----------

## nomenquis

 *holycow wrote:*   

> Man, am I glad I found this thread. You've done some outstanding work.
> 
> I got my g15 keyboard a couple days ago and have been looking for ways to use it's capability under Linux. Your patch and utility open the door for using the lcd.
> 
> I patched my 2.6.15 kernel and got it going without any issues. The g15lcd util compiled fine and I was putting text on the lcd in no time at all. I like the image support you've added too.
> ...

 

Well, that actually was the more practical approach. At first I tried it with each line of text as a seperate line but when I did this I had to change my helper programs everytime I changed the fonts on the display (becaues more or less lines of text can be displayed)

 *holycow wrote:*   

> 
> 
> Now, if only the G-keys worked...
> 
> 

 

The problem is that I'd have to handle the G keys in my code because the kernel cant share the usb interface with my program. So, no G keys for at least a while if you want to use my stuff  :Sad: 

 *holycow wrote:*   

> 
> 
> If you haven't yet, check out http://phyreskull.ithium.net/g15wiki/wiki/Main_Page. Some good work going on there too.
> 
> 

 

Well, they should be slapped for not releasing the sourcecode but only binaries. Aw, I objdump -d their libg15 and found a neat way to detach the device from the kernel. I'll post a new version soon (needs some testing) and this new version wont require the kernel patch anymore.

kind regards

----------

## nomenquis

Version 0.3 is on the homepage now ( http://waug.at/g15lcd/ ) 

The only change is that you do not need the kernel patch anymore. If you do have it applied already you do not need to recompile your kernel, it will work even with the patch applied.

Edit: please give me some feedback if this new version works for you without the kernel patch.

kind regards

----------

## nosenseofhumor1

let it be known, it works!

good job! Amazing!

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> let it be known, it works!
> 
> good job! Amazing!

 

Thats good to hear. I'm currently trying to figure out how to inject events back into the event system from userspace. Then the G keys could be made working too without any kernel drivers.

But, I have _no_ idea on how to do that sadly  :Sad: 

kind regards Philip

----------

## nosenseofhumor1

why not attack it a similar way? eat the button presses into a buffer that feeds a function in an infinate loop?

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> why not attack it a similar way? eat the button presses into a buffer that feeds a function in an infinate loop?

 

And do what with it?

No, frankly, do what with it?

All I could do is launch an application for a button press or the like, but I really dislike the idea of writing yet another stupid launcher program.

Aw, about 2 minutes after writing to the lkml I found the solution (doh'). I can simply send the keypresses up into the kernel and from there back into userspace. So, if you press Gxx when you're in X then X will receive this keypress.

Thats the way it should be (imo).

Now all thats left is to actually write the code  :Wink: 

kind regards

----------

## nomenquis

Would anyone have windows here?

I'm trying to figure out the behaviour of the keys but they're actually quite strange and someone with the logitech driver on windows could help me a great deal.

.) Is it possible to press more than 5 g keys at once in windows? I'd like to know if thats possible. What _should_ happen is that if you've already pressed 5 keys then pressing a 6th key will do _nothing_ at all.

.) The M and "L" (the small ones below the display) do not actually have a state (pressed or not pressed) but rather just send press events. This means that for instance there should be no "repeat key" function for these keys. Also it should make no difference if one key is pressed when you press a second key.

Edit: Also the M and L keys seem to only send an event when they are released. So, pressing and holding any of these keys should not have any effekt until you release the key

kind regards

----------

## nomenquis

I really do like posting a lot  :Smile: 

Aw, version 1.0 is online now. All the G M and L keys work now. Keypresses are send to the kernel which will pass them down the normal keyboard chain. This means that if you run g15lcd and press G13 or so then your X server (if your're running X, otherwise the console) will get the keypress. This is 100% compatible with the gnome keyboard shortcuts for instance. Also one could hook the input chain and react to this events to do some more advanced stuff.

This version will require you to compile a special kernel module (userspace input helper) which is included with vanilla kernel (so no patches necessary). Since v1.0 will refuse to start without the uinput stuff I've also left the old souce on the page in case you only want to display something.

Also note that g15lcd never exists anymore, so echo "foobar" | g15lcd is a pretty bad idea. Rather really create a pipe and use it.

kind regards Philip

----------

## Nondysjunction

I am currently working on an id3-tag displaying script based on the techniques  associated with this post. Thank you all for responding to my initial post.

I do have an inquiry to make, though.  When refreshing the lcd, the logitech logo that is present by default will flash momentarily. I was wondering if there was a way to make the transition more smooth.   Please note I am still using g15lcd.

If anyone is interested, the script I am writing is written in php, and currently supports single-line scrolling output, but will soon support multi-line output. Essentially, there is a pre-text which stays constant, such as an identifier for what is scrolling,  and to the right is the scrolling contiguous looping text.  Configurable scroll-rate is available. I will make this available as soon as I deem it to be of high enough quality to unleash upon the world.  :Razz: 

----------

## nosenseofhumor1

use the pipe to file method

```

mknod pipe p

nohup ./g15lcd pipe &

echo "TM \"Line 1\"\"Line2\"" > pipe

```

heres a little script i wrote just now that i thought was handy... though it could probably use some improvements

```

while [ 0 -ne 1 ]

do

 echo "TS \""`date`\"\"amixer get Master|grep '  Front L'` \"\"`amixer get Master|grep '  Front R'`\"\"`free -m|grep '\-'`\"\"`top -bn2|grep "Cpu"|grep \3`\" `sleep 3` >pipe

done &

```

just to explain the top thing... it seems as though top returns 6.6% for cpu usage every time if you take a -bn1 so i took a -bn2 and grepped for the second line.

next on the list will be to display etho tx/rx and if i have time i might clean it up, make it into a real script, and have it display screens showing the weather and graphs of cpu/net/mem/sensors/available disk space

if anybody beats me to it, let me know

my goal is to replace gkrellm... hope thats not an unreasonable task

----------

## nomenquis

 *Nondysjunction wrote:*   

> I am currently working on an id3-tag displaying script based on the techniques  associated with this post. Thank you all for responding to my initial post.
> 
> I do have an inquiry to make, though.  When refreshing the lcd, the logitech logo that is present by default will flash momentarily. I was wondering if there was a way to make the transition more smooth.   Please note I am still using g15lcd.

 

The Logitech logo is displayed everytime i reset the controller. That is only done on startup of g15lcd however. Since there is no way to avoid this thing you really should use a pipe and let g15lcd live all the time instead of always piping into a new process.

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> use the pipe to file method
> 
> ```
> 
> mknod pipe p
> ...

 

Dont use top for that. The better way to do it would be to use /proc/stat. In there you have time spend in usr / sys / nice / hi /low etc. Because if you plan on starting your script every second or so you can save a lot of cpu cycles if you do not have to start top. However if you use /proc/stat you will have to remember the previous values sind you're interested in the deltas.

----------

## nosenseofhumor1

yeah that was my intention at first, but i couldnt figure out how to read it.... proc/stat seems to show a lot of garbage, making it readable seemed like a pain so i just grabbed it from top... suppose that was lazy of me. 

this is what a top page had to say about it

 *Quote:*   

> 
> 
> The MetaTalk handler that does all of these things is called updatelist and is shown in Listing 1. This handler, like all MetaTalk message handlers, starts with the word on and the name of the message to be handled. The first few lines of this handler declare all the local variables used in this handler. While not strictly necessary, it's a good idea to declare variables to avoid bugs caused by misspelling variable names. To check your scripts, you can set the MetaCard property explicitVariables, which will flag as an error any variable used before it was declared. 
> 
> The handler then gets the global system time statistics from the file "/proc/stat" and subtracts the values from the last time the handler was called. The time statistics are then stored in a local variable declared outside the handler, which works like a "static" variable in C: it retains its value like a global, but can only be referred to within the script (i.e., it doesn't pollute the global name space). This variable, like all MetaTalk variables, can be used as an associative array without special declarations. All you have to do is put a string (which can be a number) between the [] characters. 
> ...

 

hmm.... so i am supposed to read the line twice, subtracting the first read from the second? and with that number, how do i get a percentage of processor usage? also, wouldnt i have to be updating this accurately on the same interval to get a good number? that being said, it sounds like i might have to really complicate this script in order to eliminate the top calls.... but honestly, the load is rather small...

ill probably look further into this if i end up writing some sort of small app to marquee info to the display or show pages with charts, which i will probably begin when i come across an effective method to use the buttons right below the screen without kernel patching (i really want to use them to control what pages are displayed on the screen)... what are your thoughts?

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> yeah that was my intention at first, but i couldnt figure out how to read it.... proc/stat seems to show a lot of garbage, making it readable seemed like a pain so i just grabbed it from top... suppose that was lazy of me. 
> 
> hmm.... so i am supposed to read the line twice, subtracting the first read from the second? and with that number, how do i get a percentage of processor usage? also, wouldnt i have to be updating this accurately on the same interval to get a good number? that being said, it sounds like i might have to really complicate this script in order to eliminate the top calls.... but honestly, the load is rather small...
> 
> ill probably look further into this if i end up writing some sort of small app to marquee info to the display or show pages with charts, which i will probably begin when i come across an effective method to use the buttons right below the screen without kernel patching (i really want to use them to control what pages are displayed on the screen)... what are your thoughts?

 

Its really easy. First substract all values from a previous run (delta T does not matter)

Then sum up the difference, this should be total cpu "ticks" used in that period of time.

Now the values themselves are desrcibed in:

/usr/src/linux/Documentation/filesystems/proc.txt (Section 1.8, line 740 or so)

For instance the first value is time spend in normal user operation ( -> this delta / whole delta = % cpu used in normal tasks)

kind regards Philip

----------

## nosenseofhumor1

oh i see, that sounds simple enough to include it right in this script... ill give that a go hopefully tonight when i get out of work, maybe tomorrow. you know, the potential of this thing is staggering! here is a challenge for anybody with too much time on their hands;

write a terminal or fork a terminal app like aterm to watch user input on keypress. if the user presses the space bar, grep the man page of the preceeding command for the arg syntax and the short synopsis and output them both to the top line of the LCD.

takers?

----------

## nosenseofhumor1

one other thing; where in proc can i find eth tx/rx? i would like to show my adapter stats too

----------

## nomenquis

 *nosenseofhumor1 wrote:*   

> one other thing; where in proc can i find eth tx/rx? i would like to show my adapter stats too

 

strace is your friend  :Smile: 

strace ifconfig -a shows that /proc/net/dev might be what you want.

Btw, if you write a cool script please mail it to me  :Smile: 

kind regards Philip

----------

## Nondysjunction

 *nomenquis wrote:*   

>  *Nondysjunction wrote:*   I am currently working on an id3-tag displaying script based on the techniques  associated with this post. Thank you all for responding to my initial post.
> 
> I do have an inquiry to make, though.  When refreshing the lcd, the logitech logo that is present by default will flash momentarily. I was wondering if there was a way to make the transition more smooth.   Please note I am still using g15lcd. 
> 
> The Logitech logo is displayed everytime i reset the controller. That is only done on startup of g15lcd however. Since there is no way to avoid this thing you really should use a pipe and let g15lcd live all the time instead of always piping into a new process.

 

Point well taken. I will do this from now on.

----------

## nomenquis

Hi,

another new version (1.2) is online. I also rewrote the page a little bit (more ads :p) http://waug.at/g15lcd/

The major changes are:

You can now turn the key handling off if your kernel does not support uinput (so no excuses for using an old version)

No input is read from stdin anymore, you have to use a pipe now

You can turn off the lcd handling if you dont want it (eg. you just want the keys handled)

You can specify the path to the uinput device (looks like something was changed with newer udev versions).

Cleaned up the code a whole lot

Tested everything with valgrind for problems, looks like nothing is doing bad stuff.

Well, thats about it, have fun

kind regards

----------

## Nondysjunction

Heres a thought: perhaps a compatibility layer between the api used to make mods and applets in Windows. and g15lcd!

the source files for almost all the applets is available, as well as an SDK iirc.

----------

## holycow

I'm very happy to have the G, M and L keys working.

I feel like I've got a "complete" keyboard now.  :Very Happy: 

Very good job, nomenquis. Many kudos to you.

----------

## nomenquis

 *Nondysjunction wrote:*   

> Heres a thought: perhaps a compatibility layer between the api used to make mods and applets in Windows. and g15lcd!
> 
> the source files for almost all the applets is available, as well as an SDK iirc.

 

Well, thats something I've been discussing with the guys who wrote the other g15 app (url somewhere on page 1).

I'm not a big fan of the idea however as windows and linux are two totally different platforms. On Linux you will have to take care about a lot of things (including security problems) which seem to be of no concern for the windows guys.

If however you can give me a good plan for implementing such an api compatibility layer then I might consider doing it.

In principle everything needed for an api compatibility layer is already here however. They keypresses could be cought by x11 app and this app could also display data in pretty much the same format as used in windows on the lcd.

But, how will you handle "locking" the display exclusively for one process, or replaying macros without opening a whole can or worms which will lead to both, very complex code and potential danger?

I'm really open for suggestions.

kind regards Philip

----------

## nomenquis

I just searched around a little bit and found a good way to implement the macro functionality on linux.

In principle you need xbindkeys (portage) and xsendkey http://pag.csail.mit.edu/~adonovan/hacks/xsendkey.html

Now in my xbindrc i have something like

"/home/philip/macro.sh 1 &"

    m:0x0 + c:130

    NoSymbol

and macro.sh 2 and so on for different macros.

and in macro.sh I have

xsendkey i

xsendkey f

xsendkey " "

and so on. 

Please note however that X11 seems to toy around with the scancodes I send from g15lcd currently. So while X will receive the scancodes I describe in the readme thats not what xbindkeys will receive since X seems to change things accoring to your keyboard model. Someone should create a better keyboard model which will simply pass these scancodes through without modifications.

Quite a hack but this seems to work nicely. Perhaps I'll write a simple tool combining the two tools but I'm busy with other things right now.

kind regards

----------

## kalis0

hmmm... taking a wild guess here, but maybe this LCD has some connection with the Logitech diNovo media pad LCD (which IIRC exists both in bluetooth and in "classical RF wireless") ? anyone willing to take a look at it?

----------

## nosenseofhumor1

hey everyone...finally got around to it and wrote a script for this thing. make improvements... think of other useful things to include in it!

```

      1 #!/bin/bash

      2 # This is a little script that grabs the date,

      3 # volume on the alsa mixer,available memory,

      4 # cpu usage, and current RxTx/sec and pipes

      5 # them to g15lc to be displayed.

      6

      7 # As of right now this script must be in the

      8 # same directory as the g15lcd app.

      9 # Obvious improvements to come.

     10

     11 # some freaking thing is slowing this down DRASTICALLY.

     12 # ask a forum.

     13

     14 `mknod pipe p`

     15 exec nohup ./g15lcd pipe &

     16 # get a cpu sample to get us started

     17 DATA=`cat /proc/stat | grep 'cpu ' | awk '{ FS=" "; printf "%s %s %s %s",$2,$3,$4,$5;}'`

     18 us1=`echo $DATA | cut -d' ' -f1`

     19 ni1=`echo $DATA | cut -d' ' -f2`

     20 sys1=`echo $DATA | cut -d' ' -f3`

     21 idle1=`echo $DATA | cut -d' ' -f4`

     22 while :

     23 do

     24         # okay, im looking for tx/sec and rx/sec on eth0

     25         DATA=`awk '/eth0/ { FS=" "; printf "%s %s",$2,$10;}'</proc/net/dev`

     26         sleep 1 # so i better get the delta for 1 elapsed second, right?

     27         DATA2=`awk '/eth0/ { FS=" "; printf "%s %s",$2,$10;}'</proc/net/dev`

     28

     29         Rx=`echo $DATA | cut -d' ' -f1`

     30         Tx=`echo $DATA | cut -d' ' -f2`

     31

     32         Rx2=`echo $DATA2 | cut -d' ' -f1`

     33         Tx2=`echo $DATA2 | cut -d' ' -f2`

     34

     35         RxDelta=' Rx:'$((Rx2 - Rx))

     36         TxDelta='Tx: '$((Tx2 - Tx))

     37

     38         # on to CPU usage

     39         DATA=`awk '/cpu / { FS=" "; printf "%s %s %s %s",$2,$3,$4,$5;}'</proc/stat`

     40

     41

     42         us=`echo $DATA | cut -d' ' -f1`

     43         ni=`echo $DATA | cut -d' ' -f2`

     44         sys=`echo $DATA | cut -d' ' -f3`

     45         idle=`echo $DATA | cut -d' ' -f4`

     46

     47         usDelta=$((us - us1))

     48         niDelta=$((ni - ni1))

     49         sysDelta=$((sys - sys1))

     50         idleDelta=$((idle - idle1))

     51

     52         ((cpuDelta=usDelta + niDelta + sysDelta + idleDelta))

     53         usPct=`echo "scale=2;$usDelta/$cpuDelta" |bc`

     54         usPct=' user:'`echo "$usPct*100" |bc|cut -d'.' -f1`%

     55

     56         niPct=`echo "scale=2;$niDelta/$cpuDelta" |bc`

     57         niPct=' nice:'`echo "$niPct*100" |bc|cut -d'.' -f1`%

     58

     59         sysPct=`echo "scale=2;$sysDelta/$cpuDelta" |bc`

     60         sysPct=' sys:'`echo "$sysPct*100" |bc|cut -d'.' -f1`%

     61

     62         us1=$us

     63         ni1=$ni

     64         sys1=$sys

     65         idle1=$idle

     66

     67         # just a few other things i wanted to throw in there.

     68         myDate=\"`date`\"

     69         frontL=\"`amixer get Master|grep '  Front L'`\"

     70         frontR=\"`amixer get Master|grep '  Front R'`\"

     71         myFree=\"`free -m |grep '\-'`\"

     72

     73         # then to set the other lines up so this info all shows up on one line each

     74         cpuNet="\"$usPct $niPct $sysPct\""

     75         eNetDelta="\"$TxDelta $RxDelta\""

     76

     77         # and send it all to pipe

     78         `echo "TS $myDate $frontL $frontR $myFree $cpuNet $eNetDelta" > pipe`

     79

     80 done

```

the Rx and Tx deltas... i dont know what they actually signifiy... my intention was kbps... can somebody verifiy that?

next projects: marquee display. multi toggle screens. graphing. ....weather? ...xmms? oooooooo! know what would be super cool!? if somebody could figure out a way to put the xmms dot scope analyzer on this screen in realtime! oooooooooo.... anybody up for that challange?

----------

## Jazz

Ran the script, runs beautifully.. but can the font be changed ? as the current font is quite small. I like the size and the fonts displayed with the default G15 drivers in windows !

but it's really awesome, to be able to use all the keys with Linux..

For now, maybe instead of diaplaying all the info in the LCD, maybe we can have different scripts to display like CPU/RAM, XMMS Media info, etc etc, on different screens whcich can be called or changed by using the 4 buttons under the LCD ?

Can this be implemented without much hassles ?

Again, thanx for getting support for this keyboard under Linux.

Bye,

Jazz

----------

## nosenseofhumor1

i havent seen the buttons under the screen working just yet, but that is my plan; thanks  :Smile: 

yeah you can change the font. change the "TS" in line 78 to "TM"... i just didnt want to run out of room...

what im working on now is graphs. perhaps a one second toggle between graphs. i successfully animated a gentoo logo on it this morning; so as soon as i get a few hours i should be able to knock out the graphing functions.

Steve

--update--

i really dont get a lot of time to dink with this.... it might just take a few hours, but it could be days weeks or a month before i get the time.

----------

## Aynjell

 *nomenquis wrote:*   

> Hi,
> 
> I started writing a driver for this one. It seems to work pretty well.
> 
> http://www.waug.at/g15lcd/
> ...

 

Oh, my, god, you rule. Please keep working, and if you get this going, I might buy one. My saitek eclipse is really starting to suck. If you can make it show CPU usage, memory usage and total, and possibly cpu tempurature, I'd be set.

----------

## nosenseofhumor1

thats all here Aynjell, go through the thread again.

----------

## Aynjell

I'm aware. Thanks mate. But yeah, even if you do get this working, I'm still waiting for the turantula.

----------

## bMd

sorry am I missing somthing??

i untar it & do make then get:

```

bmd@local ~/g15lcd-1.2-pre0 $ make

g++ -O2 -Wall -pedantic -c font_8x8.cpp

g++ -O2 -Wall -pedantic -c font_7x5.cpp

g++ -O2 -Wall -pedantic -c font_6x4.cpp

g++ -O2 -Wall -pedantic -c lcd.cpp

lcd.cpp:22:17: usb.h: No such file or directory

make: *** [all] Error 1

```

 any help?

----------

## nosenseofhumor1

looks like youre missing usb.h

 :Smile: 

its probably in libusb

try emerging that.

----------

## bMd

duh  :Embarassed: 

compiles fine now, gonna try when I get back home.

Thanks

----------

## nosenseofhumor1

you got it  :Smile: 

btw i found a way to get xmms now playing info to display on the screen:

first you need to emerge xmms-infopipe

restart xmms, goto plugins, and enable the infopipe plugin.

then someplace inside my script's loop sat a variable equal to the contents of /tmp/xmms-info grepping for 'Title: '

throw quotes around the variable's contents like this

XMMSINFO="\"$XMMSINFO\""

and add $XMMSINFO to the line that echo's the variables into 'pipe'

my script has gotten a little sloppy, so if anybody wants to improve it, please do and post the results. There are two places that need obvious improvement (whats a substring?). They are denoted with 

 *Quote:*   

> 
> 
>  ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###
> 
> 

 

Whatever... Im not a bash scripter by any standard. Never-the-less, just in case anybody wants it, here is my script as it stands today:

```

 #!/bin/bash

 # This is a little script that grabs the date,

 # volume on the alsa mixer,available memory,

 # cpu usage, and current RxTx/sec and pipes

 # them to g15lc to be displayed.

 # As of right now this script must be in the

 # same directory as the g15lcd app.

 # Obvious improvements to come.

 `mknod pipe p`

 exec nohup ./g15lcd pipe &

 # get a cpu sample to get us started

 DATA=`cat /proc/stat | grep 'cpu ' | awk '{ FS=" "; printf "%s %s %s %s",$2,$3,$4,$5;}'`

 us1=`echo $DATA | cut -d' ' -f1`

 ni1=`echo $DATA | cut -d' ' -f2`

 sys1=`echo $DATA | cut -d' ' -f3`

 idle1=`echo $DATA | cut -d' ' -f4`

 # an infinate loop

 while :

 do

         # okay, im looking for tx/sec and rx/sec on eth0

         DATA=`awk '/eth0/ { FS=" "; printf "%s %s",$2,$10;}'</proc/net/dev`

         # so i better get the delta for 1 elapsed second, right?

         sleep 1 

         DATA2=`awk '/eth0/ { FS=" "; printf "%s %s",$2,$10;}'</proc/net/dev`

         Rx=`echo $DATA | cut -d' ' -f1`

         Tx=`echo $DATA | cut -d' ' -f2`

         Rx2=`echo $DATA2 | cut -d' ' -f1`

         Tx2=`echo $DATA2 | cut -d' ' -f2`

         RxDelta=' Rx:'$((Rx2 - Rx))

         TxDelta='Tx: '$((Tx2 - Tx))

         # on to CPU usage

         DATA=`awk '/cpu / { FS=" "; printf "%s %s %s %s",$2,$3,$4,$5;}'</proc/stat`

         us=`echo $DATA | cut -d' ' -f1`

         ni=`echo $DATA | cut -d' ' -f2`

         sys=`echo $DATA | cut -d' ' -f3`

         idle=`echo $DATA | cut -d' ' -f4`

         usDelta=$((us - us1))

         niDelta=$((ni - ni1))

         sysDelta=$((sys - sys1))

         idleDelta=$((idle - idle1))

         ((cpuDelta=usDelta + niDelta + sysDelta + idleDelta))

         usPct=`echo "scale=2;$usDelta/$cpuDelta" |bc`

         usPct=' user:'`echo "$usPct*100" |bc|cut -d'.' -f1`%

         niPct=`echo "scale=2;$niDelta/$cpuDelta" |bc`

         niPct=' nice:'`echo "$niPct*100" |bc|cut -d'.' -f1`%

         sysPct=`echo "scale=2;$sysDelta/$cpuDelta" |bc`

         sysPct=' sys:'`echo "$sysPct*100" |bc|cut -d'.' -f1`%

         us1=$us

         ni1=$ni

         sys1=$sys

         idle1=$idle

         # just a few other things i wanted to throw in there.

         myDate=\"`date`\"

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         # Okay, here's the story with this:

         # since i dont know how to use the substring functions of bash, 

         # this loop goes through each string returned by $volume

         # ignores the first three strings, and takes whatever is left on the line

         # into vol.

         # i should have done this with a counter, but i only thought i was going to 

         # ignore the first string... then it became the first two strings

         # .... then it became the frist three. Im too lazy to change it to a counter,

         # especially considering that it should be replaced entirely by a substring function

         # that just grabs everything after the thrid word.

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         volume=`amixer get Master | grep '  Front L'`

         vol=""

         ISFIRST="TRUE"

         for x in $volume

         do

                 if [ $ISFIRST = "FALSE" ]

                 then

                         vol="$vol $x"

                 else

                         if [ $ISFIRST = "TRUE" ]

                         then

                                 ISFIRST="ISSECOND"

                         else

                                 if [ $ISFIRST = "ISSECOND" ]

                                 then

                                         ISFIRST="ISTHRID"

                                 else

                                         ISFIRST="FALSE"

                                 fi

                         fi

                 fi

         done

         vol="\"Volume: $vol\""

         myFree=\"`free -m |grep '\-'`\"

         # then to set the other lines up so this info all shows up on one line each

         cpuNet="\"$usPct $niPct $sysPct\""

         eNetDelta="\"$TxDelta $RxDelta\""

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         # lets get some xmms info too. 3/5/06

         # heads up: this is a similar nightmare to what i have up above for the 

         # volume parser.

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

         DATA=`cat /tmp/xmms-info | grep 'Title: '`

         ISFIRST="TRUE"

         xmmsinfo=""

         for x in $DATA

         do

                 if [ $ISFIRST = "TRUE" ]

                 then

                         ISFIRST="FALSE"

                 else

                         xmmsinfo="$xmmsinfo $x"

                 fi

         done

         xmmsinfo="\"$xmmsinfo\""

         # and send it all to pipe

         `echo "TS $myDate $vol $myFree $cpuNet $eNetDelta \"\" $xmmsinfo" > pipe`

 done

```

thanks folks!

----------

## LAsk

 *kalis0 wrote:*   

> hmmm... taking a wild guess here, but maybe this LCD has some connection with the Logitech diNovo media pad LCD (which IIRC exists both in bluetooth and in "classical RF wireless") ? anyone willing to take a look at it?

 

I'd also like to know if anyone has tested this. Would be really cool if it'd work.

----------

## piranha2001

 *LAsk wrote:*   

>  *kalis0 wrote:*   hmmm... taking a wild guess here, but maybe this LCD has some connection with the Logitech diNovo media pad LCD (which IIRC exists both in bluetooth and in "classical RF wireless") ? anyone willing to take a look at it? 
> 
> I'd also like to know if anyone has tested this. Would be really cool if it'd work.

 

 :Shocked:  I'm still curious: Is there a possibility of getting the DinNovo Media-Pad's LCD to work with Linux?   :Question: 

----------

## nosenseofhumor1

sure its possible... i dont have one, so i have no idea how, but if you want to take a crack at it; usbsnoopy on a windows box should give you most of the information you need to get started and then some... you might want to start a new thread asking other dinovo users if they have taken a shot at it.

----------

## Guntard

Hi, 

I think I'm gonna buy the Logitch G15 Keyboard, but before I do so I'd like to know two things (I ask here because I can"t seem to find those informations anywhere on the net)  :

Do the G-keys have there proper keycode viewable with xev and configurable with khotkey ?

On the logitech's webpage they write that there are 3 level of backlight. How does that work ? Can you manage them manually, or is it a captor that make it glow ? Does it work under Gentoo ?

Thanks in advance for the input. And I must sayt that you've done a great work with the LCD screen. It's the main reason why I think I'm going to buy the keyboard.  :Razz: 

Guntard

----------

## nosenseofhumor1

hear that logitech? youre welcome.

yeah the keyboard has a button on it with a little picture of a lightbulb that allows you to change the light intensity. its hardware controlled, so you dont have to worry about it working with linux.

the g keys, however, are not your standard key. these things are pretty tricky, and they dont have real keycodes. i think nomenquis got it figured out though; take a look at his last post.

----------

## Clapper

Hi,

I've followed your thread on the Gentoo forum (I'm running Gentoo).

I have followed all your instructions, and tried compiling the uinput

in my kernel both as a module and build in directly, but am having

trouble regardless.

I can start the g15lcd program "straight", and don't get any errors:

---------------------

workstation g15lcd-1.2-pre0 # ./g15lcd -d /dev/misc/uinput

You didnt specify a fifo filename, I'm this disabling writing text to

the lcd

This is a change in behaviour from previous version, I will _NOT_ read

data from stdin anymore

Starting g15lcd with the following settings:

         fifo:          ""

         uinput device: "/dev/misc/uinput"

Found keyboard, trying to open it ...

Done opening the keyboard

Key Handling init

---------------------

so I'm assuming my kernel is ok.

I've then tried to get text displayed with this:

mknod pipe p

nohup ./g15lcd -d /dev/misc/uinput pipe  &

echo "TM \"The answer is 42\" \" and the question is ???\""  > pipe

The gl15lcd is running in the background, but my echo commands don't show

anything on the screen.  Just the Logitech logo.

Notice my device lives in /dev/misc/uinput - a little different than

other people, but I don't think this is causing the problem.

I'm using kernel linux-2.6.16-ck9

What could I be missing?

----------

## Clapper

 *Clapper wrote:*   

> 
> 
> I've then tried to get text displayed with this:
> 
> mknod pipe p
> ...

 

One other little piece to the puzzle.  The nohup.out file

generated when I run the:

nohup ./g15lcd -d /dev/misc/uinput pipe  &

echo "TM \"The answer is 42\" \" and the question is ???\""  > pipe

is as follows.  I don't know what a return value of -28 might 

signify...

```

Starting g15lcd with the following settings:

         fifo:          "pipe"

         uinput device: "/dev/misc/uinput"

Found keyboard, trying to open it ...

Done opening the keyboard

Key Handling init

Error writing to the lcd, return value is -28

The returnvalue should have been 0x03e0 however

```

----------

## Gregoire

Hello everybody,

I wrote from my brand new Logitech G15  :Smile: 

g15lcd seems to works, but it produce ton of repeated

```

usb 4-1.4: usbfs: usb_submit_urb returned -22

```

in the syslog and syslogd takes about 100% of my CPU for it...

From lspci -vv :

http://gregoire.favre.googlepages.com/lspci-vv.txt

And the config I used to compil the kernel :

http://gregoire.favre.googlepages.com/linux-2.6.17-rc4-mm3.config.txt

If someone more usb-knownledged than I could look at it and tell me what to change, I would be very thankfull to him!

Thank in advance  :Wink: 

----------

## choenig

Hi,

here you can find a patch for g15lcd 1.2 that adds support for switching the M-Lights on the G15 keyboard. 

I'm not 100% sure if this patch works on different systems, too, as I don't know, if the data to send to the keyboard is local to my system or global to the keyboard.

It would be nice if someone would test this patch  :Smile: .

Usage is pretty simple:

o get the patch and patch your g15lcd source

o compile

o run g15lcd (like you always do)

o and then send something like

```

 M 1*x0

```

to your pipe, where the four values represent the Lights M1, M2, M3 and MR. Sending a '1' switches it on, '0' switches it of, 'x' toggles its current state, and '*' (or everything else) simply leaves the corresponding light in its current state. 

take care, have fun

/christian

PS: I sent this patch to Philip (author of g15lcd), too, but he didn't reply yet.

----------

## Clapper

Anyone have any idea about this?  I *really* would like to get the display working.

I am thinking of some cool stuff I'd like to put up there!

Thanks in advance!

 *Clapper wrote:*   

> 
> 
> ```
> 
> Starting g15lcd with the following settings:
> ...

 

----------

## Durandune

i just got the g15, man you guys are doing some amazing things with it, keep it up, you should be working for a company or something, getting payed a shitload to do what ur doing,

thx

----------

## mjelkins

Played around with the code that gives some useful stats - etc... and made some minor improvements.

```

#!/bin/bash

# This is a little script that grabs the date,

# volume on the alsa mixer,available memory,

# cpu usage, and current RxTx/sec and pipes

# them to g15lc to be displayed.

#PIPE=/tmp/g15-pipe        # Pipe location

PIPE=/root/pipe          # Pipe location

XMMS=/tmp/xmms.info      # Where XMMS writes info

[ ! -p $PIPE ] && mknod $PIPE p

#exec nohup ./g15lcd $PIPE >/dev/null 2>&1 &

# Initial Ethernet sample (Bytes out/in) - sets oRx, oTx

eval $(grep eth0: /proc/net/dev|cut -d: -f2|awk '{printf "oRx=%s oTx=%s\n",$1,$9 }')

# Initial cpu sample - sets oUs, oNi, oSys, oIdle

eval $(awk '/cpu / {printf "oUs=%s oNi=%s oSys=%s oIdle=%s\n",$2,$3,$4,$5;}' < /proc/stat)

# loop forever

while true

do

        sleep 1  # This is our update delay - and how long we wait for a new sample

        eval $(grep eth0: /proc/net/dev|cut -d: -f2|awk '{printf "Rx=%s Tx=%s\n",$1,$9 }')

        eNetDelta=$(printf "\"Tx:%4s Rx:%4s\"" $(( (Tx - oTx) / 1024 ))k $(( (Rx - oRx) / 1024 ))k )

        oRx=$Rx

        oTx=$Tx

        # on to CPU usage

        eval $(awk '/cpu / {printf "Us=%s Ni=%s Sys=%s Idle=%s\n",$2,$3,$4,$5;}' < /proc/stat)

        usDelta=$((Us - oUs))

        niDelta=$((Ni - oNi))

        sysDelta=$((Sys - oSys))

        idleDelta=$((Idle - oIdle))

        ((cpuDelta=usDelta + niDelta + sysDelta + idleDelta))

        usPct=$(printf "user:%2d%%" $(( usDelta * 100 / cpuDelta )) )

        niPct=$(printf "nice:%2d%%" $(( niDelta * 100 / cpuDelta )) )

        sysPct=$(printf "sys:%2d%%" $(( sysDelta * 100 / cpuDelta )) )

        oUs=$Us

        oNi=$Ni

        oSys=$Sys

        oIdle=$Idle

        # just a few other things I wanted to throw in there.

        myDate=\"$(date)\"

        vol="\"Vol: $(amixer get Master|grep '  Front Left'|cut -d' ' -f 6-)\""

        myFree=\"$(free -m |grep '\-')\"

        # then to set the other lines up so this info all shows up on one line each

        # cpuNet="\"$usPct $niPct $sysPct\""

        cpuNet="\"$usPct $sysPct\""

        ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

        ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

        # lets get some xmms info too. 3/5/06

        # heads up: this is a similar nightmare to what i have up above for the

        # volume parser.

        ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

        ### THIS IS A POORLY CONSTRUCTED BLOCK OF CODE ###

        DATA=` [ -s $XMMS ] && cat $XMMS | grep 'Title: '`

        ISFIRST="TRUE"

        xmmsinfo=""

        for x in $DATA

        do

                if [ $ISFIRST = "TRUE" ]

                then

                        ISFIRST="FALSE"

                else

                        xmmsinfo="$xmmsinfo $x"

                fi

        done

        xmmsinfo="\"$xmmsinfo\""

        # and send it all to my pipe

        #echo "TL $myDate $vol $myFree $cpuNet $eNetDelta \"\" $xmmsinfo" > $PIPE

        echo "TL $myDate $vol $cpuNet $eNetDelta $xmmsinfo" > $PIPE

done

```

As my xmms creates a socket called xmms_mje.0 - I had difficulty improving the original authors code. I also prefer large font (cleaner to read) and changed the Ethernet Packet count to Traffic (Kb). The original author did all the real work though.

----------

## Y4kk0

1st of all big thx to the nomenquis for the g15lcd tool.

I am really pleased with the prog. I received today the keyboard, and after 30 mins I got it already working. 

Than many thanks to nosenseofhumor1 & mjelkins for creating the script.

Found out that when uinput is loaded as a module it worked without like a charm. But when I build it into the kernel it wouldn't load. Changed it back, and its running now as a module.

I had to change a couple of things in the script to get the XMMS stuff to work.

A minor issue was that on my system /tmp/xmms.info actuaully should be /tmp/xmms-info 

Than this is linked against a /tmp/xmms-info.username. 

Therefore I had to chang the test for a file into a test for a Link.

changed : 

```
DATA=` [ -s $XMMS ] && cat $XMMS | grep 'Title: '`
```

into : 

```
DATA=` [ -L $XMMS ] && cat $XMMS | grep 'Title: '`
```

And now its working a bit better.  

Also added a line for Uptime but need to test it a lil further. 

Once it is working I will do an update.

Damn I am pleased with this piece of good work.

----------

## twam

Maybe something find this interesting...

/usr/local/portage/app-misc/g15lcd/g15lcd-1.2_pre0.ebuild

```
# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/app-misc/g15lcd/g15lcd-1.2.ebuild,v 1.6 2006/06/27 20:50:00 twam $

inherit eutils

DESCRIPTION="Software to interface Logitech's G15-Gamer-Keyboard"

HOMEPAGE="http://www.waug.at/g15lcd"

SRC_URI="http://www.waug.at/g15lcd/${PN}-1.2.tar.gz"

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~amd64 ~x86"

IUSE=""

RDEPEND=""

DEPEND=""

src_unpack() {

        unpack ${PN}-1.2.tar.gz

        cd "${WORKDIR}/g15lcd-1.2-pre0"

}

src_compile() {

        cd "${WORKDIR}/g15lcd-1.2-pre0"

        emake || die "make failed"

}

src_install() {

        cd "${WORKDIR}/g15lcd-1.2-pre0"

        mkdir "${D}/usr"

        mkdir "${D}/usr/sbin"

        cp g15lcd "${D}/usr/sbin"

}
```

/etc/init.d/g15lcd

```
#!/sbin/runscript

# Copyright 1999-2004 Gentoo Foundation

# Distributed under the terms of the GNU General Public License, v2 or later

# $Header: /etc/init.d/g15lcd 2006/06/22 20:50:00 twam $

opts="${opts}"

start() {

        mknod /dev/g15lcd pipe

        start-stop-daemon --start --quiet --background --exec /usr/sbin/g15lcd -- -d /dev/misc/uinput /dev/g15lcd

        eend ${result_start}

}

stop() {

        start-stop-daemon --stop --quiet --name g15lcd

        rm /dev/g15lcd

        eend $?

}
```

----------

## drdnl

Hi,

sorry to have to bring this subject back up again but where can I find usb.h? Tried searching my pc for it but nothing.

Can anyone help me get this program running?

Regards,

D

----------

## fresh corpse

 *choenig wrote:*   

> Hi,
> 
> here you can find a patch for g15lcd 1.2 that adds support for switching the M-Lights on the G15 keyboard. 
> 
> 

 

That is exactly what I searched for :-)

I wrote another patch on top of yours that prevents the LCD to be cleared when the M-Lights are changed:

http://corpse.servebeer.com/pub/save-buffer.patch

----------

## antst

Does somebody know how to bind now G-keys scancodes to particular key combinations, for example Ctrl+W ?

I tried xbindkeys+xvkbd and it doesn't work  :Sad: 

Actually with xbindkeys, if, for example I bind G-keys to some commands, like "xterm", it starts xterm.

But when I bind to "xvkbd" command (like I do for my MX1000 buttons) windows doesn't receive events.

For example ( from .xbindkeysrc):

1) 

----------------

"xvkbd -text "\C\[Page_Up]""

m:0x10 + b:6

----------------

This send Control+PageUp to windows when I press button on mouse and it works well.

2)

----------------

"xfterm4"

m:0x10 + c:177

----------------

This open terminal when I press G1 and it works well

but when I combine two above

----------------

"xvkbd -text "\C\[Page_Up]""

m:0x10 + c:177

----------------

Window doesn't receive Control+PageUp when I press G1  :Sad: 

Some advices?

----------

## antst

Argggh!

I forgot -xsendevent  :Smile: 

----------

## antst

g15lcd is nice, but limitation for number of fonts and font sizes has brought to my mind idea about rewrite code and use freetype library for rendering of text and some other improvements.

Actually, I never wrote something for freetype, but it seems to be not so difficult.

It would be not bad to discuss what's exactlu should be implemented in new engine.

----------

## antst

http://cmsmaster.tnw.utwente.nl/~antst/g15renderer.tar.gz

this is small and ugly (I never worked with fonts before) application, which can render any multiline text with any (at least any truetype) font with any size for G15.

For compillation program requres media-libs/freetype to be installed.

Usage is simple :

echo "some text" | g15renderer font_file_name font_size line_offset > g15lcd_pipe_file.

argument "line_offset" is optional, if you want to make text dense - put negative number. I had to add it because it is not clear for me how to make it in better way, I never worked with freetype and fonts before.

example:

```

echo -e "this is \nmy new shiny G15\nkeyboard" | g15renderer  /usr/share/fonts/corefonts/arial.ttf 15 -1 > /var/run/g15-pipe

```

This will print on display 3 lines of text.

One extra advantage of this way is that you can pipe to g15lcd some text with newlines, for example tail of logfiles.

----------

## antst

BTW, this program is just for testing.

Idea is to implement this functionality with some extentions directly in g15lcd.

----------

## antst

It works perfectly with bitmap fonts (pcf.gz) in this case size is ignored, clear why.

----------

## antst

I've added custom font functionality to g15lcd, also I included M-state patches and make g15lcd-1.3 version (I guess original author doesn't care anymore about project).

So, updated ebuilds and files are in bugzilla https://bugs.gentoo.org/show_bug.cgi?id=123341

Next step is to include option to render text on top of background picture.

----------

## akusarujin

I have downloaded the latest release of the g15lcd application and tried it out, with no success. I have listed the details below; can anyone help out?

A quick run of the program results as so:

 *Quote:*   

> eric@vepar:~/Desktop/g15lcd-1.2-pre0$ ./g15lcd pipe
> 
> Starting g15lcd with the following settings:
> 
>          fifo:          "pipe"
> ...

 

What exactly does "error setting the configuration" mean, anyway?

The kernel module "uinput" is loaded, and the device for it is (or should be) "/dev/input/uinput":

 *Quote:*   

> eric@vepar:~/Desktop/g15lcd-1.2-pre0$ lsmod | grep uinput
> 
> uinput                  8192  0
> 
> eric@vepar:~/Desktop/g15lcd-1.2-pre0$ ls -l /dev/input/uinput
> ...

 

The file, "pipe", is a FIFO, created as instructed in the README file:

 *Quote:*   

> eric@vepar:~/Desktop/g15lcd-1.2-pre0$ ls -l pipe
> 
> prw-r--r-- 1 eric eric 0 2006-07-16 20:50 pipe

 

The keyboard seems to be recognized properly by the kernel, also:

 *Quote:*   

> eric@vepar:~/Desktop/g15lcd-1.2-pre0$ dmesg | grep Logitech
> 
> input: Logitech Logitech Gaming Keyboard as /class/input/input1
> 
> input: USB HID v1.10 Keyboard [Logitech Logitech Gaming Keyboard] on usb-0000:00:1d.2-2.1
> ...

 

Thanks in advance for any pointers!

----------

## xante

I can get the lcd to work fine... But when it comes to the extra keys, they will not work for me.  I did have the whole G-15 Keyboard working at one point in time when xorg accepted me to use the kbd driver.  Now when I use the kbd driver and push a button X flops around and eventually dies.  Im stuck with the evdev driver and am having trouble with the extra keys.  What is everyone else using for a keyboard driver?

xorg-7.0-r1 

fluxbox-0.9.15.1-r1

----------

## z33k

Has anyone tried getting g15lcd + xbindkeys + xvkbd to send the G# key events to World of Warcraft?

I have g15lcd working to capture the G key events.  I set up a line in my .xbindkeysrc below to capture G1 and "bind" it to CTRL-F1, but when i go into World of Warcraft it doesnt recognize the event.  Is there something special I need to do with cedega to get it to work correctly?

.xbindkeysrc 

```
"xvkbd -text "\C\[F1]" -xsendevent"

m:0x10 + c:177
```

xev output when i hit G1

```

FocusOut event, serial 28, synthetic NO, window 0x3600001,

    mode NotifyGrab, detail NotifyAncestor

KeyPress event, serial 28, synthetic YES, window 0x3600001,

    root 0xba, subw 0x0, time 0, (1,1), root:(1,1),

    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,

    XLookupString gives 0 bytes: 

    XmbLookupString gives 0 bytes: 

    XFilterEvent returns: False

KeyPress event, serial 28, synthetic YES, window 0x3600001,

    root 0xba, subw 0x0, time 0, (1,1), root:(1,1),

    state 0x4, keycode 67 (keysym 0xffbe, F1), same_screen YES,

    XLookupString gives 0 bytes: 

    XmbLookupString gives 0 bytes: 

    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic YES, window 0x3600001,

    root 0xba, subw 0x0, time 0, (1,1), root:(1,1),

    state 0x4, keycode 67 (keysym 0xffbe, F1), same_screen YES,

    XLookupString gives 0 bytes: 

KeyRelease event, serial 28, synthetic YES, window 0x3600001,

    root 0xba, subw 0x0, time 0, (1,1), root:(1,1),

    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,

    XLookupString gives 0 bytes: 

FocusIn event, serial 28, synthetic NO, window 0x3600001,

    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 28, synthetic NO, window 0x0,

    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
```

Any help is greatly appreciated.  And thanks to all those who put time in to make the G15 work in linux. :0

----------

## Headrush

 *Gregoire wrote:*   

> Hello everybody,
> 
> I wrote from my brand new Logitech G15 
> 
> g15lcd seems to works, but it produce ton of repeated
> ...

 

I am seeing this same error and it is flooding syslog.

For me the problem doesn't exist with gentoo-sources-2.6.17-rX, but all gentoo-source-2.6.18 and newer kernels cause this error.

Anyone else seeing this lately?

----------

## japsu

 *Headrush wrote:*   

>  *Gregoire wrote:*   Hello everybody,
> 
> I wrote from my brand new Logitech G15 
> 
> g15lcd seems to works, but it produce ton of repeated
> ...

 

I'm having the same problem with the current ~x86 g15daemon and Linux 2.6.19. Also my G, M and L keys don't work - just the ones that emit normal keycodes anyway.

----------

## rbu

 *japsu wrote:*   

> 
> 
> usb 4-1.4: usbfs: usb_submit_urb returned -22
> 
> 

 

See bug #157852. The bug is already fixed upstream and will be in Portage today I hope.

--rbu

----------

## GenKreton

I have spent the better part of today collecting and sifting through the data about the g15 keyboard. Some of it is quite old and the various changes in the tools made ti a tad difficult. However, I do have most things working and I spent time fixing up the gentoo-wiki page on it. The information and structure still needs a lot of work but it can greatly help people who are just buying on of these keyboards.  I invite everyone else to also help fix it up since many of you have spent more time on this. 

A few notes, the amarok script will not work for me but all of the lcdproc scripts I have tried work great! All of the macro keys are working inside my KDE, but unfortunately I cannot get them to function inside of the two games I tested them in. perhaps the game is not letting the keystrokes get to xbindkeys, I cannot be sure since I know too little about this.

----------

## rbu

 *GenKreton wrote:*   

> A few notes, the amarok script will not work for me but all of the lcdproc scripts I have tried work great!

 

What's wrong with the amarok script? Can you give some details on how it's not working? Thanks.

Robert

----------

## GenKreton

I posted about this in the other major g15 thread where the amarok script was of discussion. Basically I get an error where it tries to call print() on a filehandle it says is closed.  This appears very strange to me since I see it being called to be opened in the code. As per the instructions of the maintainer on the Ubuntu forums, while he was trying to help other people, not me,  I downloaded the SVN version but that did not help me either. The output log is spammed with this, and only this error, but the line numbers change to refer to every line printing to PIPE.

```

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 22.

```

----------

## rbu

GenKreton:  Did you only update the amarok script or the whole of g15composer from svn?

Maybe this is a result of bug #158321. Please check whether upgrading to g15composer-3.1 fixes this for you. And don't forget to set the user running amarok in the conf.d.

If it does not help, please file a bug.

----------

## GenKreton

Alright, thank you. I only grabbed the script from SVN. I just synced and saw the new g15composer today so I will try it! The lcd is working great with all that said. I feel ready enough to start writing a few little screens for lcdproc or g15composer myself. It seems a bit more productive to make them for lcdproc if I ever do anything worthy of sharing. 

Now I just need to figure out why my keys aren't being passed to my games. I have only tried enemy-territory and I will try others later. The macros for my CAD program are amazing - an incredible time saver. 

It seems that ET might be taking the key, not knowing what to do, and dropping it instead of letting xbindkeys handle it and then ET interpreting the results. The LCD keys and the G1 key (options for lcdproc) both work so there MUST be a way to ensure xbindkeys gets it and passes it to the active application like it should be. Any ideas?

----------

## GenKreton

I am still getting the errors. This entire block is what is repeated in the script manager's error window for the script:

```
print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 134.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 135.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 136.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 137.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 138.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 139.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 140.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 141.

print() on closed filehandle PIPE at /usr/share/apps/amarok/scripts/g15-display.pl line 142.
```

----------

