----- Forwarded message from [EMAIL PROTECTED] ----- Date: Wed, 02 Aug 2000 15:34:58 -0500 From: [EMAIL PROTECTED] Subject: Re: evdev inputs in libgii To: Andreas Beck <[EMAIL PROTECTED]> X-Mailer: Mutt 0.95.3i On Tue, Aug 01, 2000 at 06:38:34PM +0200, Andreas Beck wrote: > [Ann.: Could you try to make the lines wrap at a suitable place ? TNX.] > > > I tested my USB keyboard by smacking keys on it, while nothing happened. > > AFAIK this is correct behaviour, as the USB keyboard isn't considered to be > a primary input device and thus ignored by the Linux console, which is a > design flaw IMHO, but I won't complain any more about the broken design of > the Linux console subsystem. actually, you are allowed to insert the module keybdev.o, which will combine it with the main keyboard. but we don't want to do that... we want to do it the manly way ;) > > > Then i typed "cat /dev/Input0", and smacked some more keys.... strange > > strings scrolled past my screen showing that the kernel side works. > > Yes. That sounds good. > > > Then i downloaded the ggi 7/28/00 snaphot, and compiled libggi. when i > > typed ./configure it said "checking if we should build linux-evdev inputlib > > ... no". That obviously wasn't good, so i looked in ./configure and found > > ... some possible options. i tried "./configure --enable-linux-evdev" and > > ... "./configure--enable-linux_evdev". neither made any differnce. > > Hmm - CVS isn't responsive right now. I'd have to upgrade to have a look. > Usually these should force it. > > > I noticed in config.h that it said i do not have a linux/input.h header > > file. so i looked and /usr/include/linux/input.h didn't exist, since my > > glibc6 was compiled with a 2.2 kernel. > > That's a bit strange. On my system, /usr/include/linux already _is_ > symlinked to /usr/src/linux/include/linux ... And I don't think I did this > by hand ... i investigated this, and i'm told that the way it's *supposed* to be, is that /usr/include/linux contains the headders that your glibc was compiled with, where as /usr/src/kernel-headders (or whereever you want them) is supposed to keep the headers of your current kernel, for the purposes of creating modules. Now i'm also told that i shouldn't leave /usr/include/linux linked to /usr/src/kernel-headers/... because it can break other apps. (note, i'm running a debian system, so this issue is probably logged somewhere) > > > i tried linking /usr/include/linux to /usr/src/kernel-headers-2.4.0-test4, > > and that didn't seem to help... don't know why. > > Did you remove config.cache ? ok, i have found that the combination of removing config.cache, linking /usr/include/linux, and --enable-linux-evdev gets it to say "yes". compilation & installation now works just peachy. thanks. > > > at this time i tried setting export GII_INPUT=/dev/Input0, and running > > mhub. mhub complained that it couldn't load linux-evdev.so. > > Yeah, as it wasn't compiled. > > > anyway, eventually i just decided to cd to the linux-evdev directory, > > and typed "make; make install", which successfully made the target > > and installed it in /usr/local/... > > In that case configure was at fault. If it wasn't the "stale config.cache" > problem, we should investigate. > > > I tried running mhub and while it no longer complined about finding > > linux-evdev.so, i couldn't figure out what mhub was supposed to do, > > so it wasn't a good test of the keybaord ;) > > Mhub is a mouse-translator. > > > Then i ran monitest, and it totally ignores the evdev device, > > and uses the main keyboard. What am i doing wrong? > > You did set GGI_INPUT - did you ? yep, i'm using export GII_INPUT=linux-evdev:/dev/input/event0 export GGI_DISPLAY=fbdev:/dev/fb1 (/dev/input/event0 is a link to /dev/Input0, which i've tested) also, i've run as root, to show it's not a permission problem. unfortunately, after building it through proper means, monitest, and xggi, still fail to access the new keyboard. they access the old "console keyboard" though, so i can still quit the applications. other notes: i've also tried /dev/input/event1 (a usb mouse), and it ends up grabbing the /dev/mouse mouse, even though i've given it no command line to use it. This is kinda concerning. *****note****** be careful when testing USB devices with GGI_INPUT. It can uncover a kernel bug in the 2.4.0-test series USB code that kills the scheduler. My machine has been rebooted many times these last two weeks :) > > The usual syntax is "GGI_INPUT=target:options" btw. > > Also always mind the difference between GGI and GII. > > > (after getting this all written, i just realized a question..... > > does monitest use GII? if not, what programs do?) > > All LibGGI programs implicitly use LibGII, unless you do really weird > contortions to avoid it. However they use their own way of detecting the > right inputs to use for a given display type, so they also have their own > override variables. > > > CU, ANdy > > -- > = Andreas Beck | Email : <[EMAIL PROTECTED]> = > Corey ----- End forwarded message ----- -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
