On 2010/04/10 12:43, Jens Teglhus Mxller wrote: > On 09-04-2010 15:06, Stuart Henderson wrote: > >On 2010-04-09, Jens Teglhus M?ller<j...@mostlyharmless.dk> wrote: > >>Is it possible for a process to consume all output for a (this) particular > >>keyboard > >I don't know about that.. > > What i was fishing for was if it is possible in a simple way (like > having a process read from /dev/ukbd* or something similar) that > would consume the data and not have it output on the terminal.
It might be possible, but that's the thing I don't know about. > >>or do i have to force it into ugen (is that even possible) and > >you already know how to force it into ugen, same thing you did > >for the Velleman kit :) > > Yeah at the time of writing i was just a little unsure if ubkd was a > uhid device and therefore could be forced into ugen with a quirk, but > when i look at the man page i can see that ukbd attaches at uhiddev. > > >I'm not sure if that would make sense to commit this one though, > >as presumably some people will want the device to present keyboard input.. > > No, i can see that perhaps i will need to keep a local diff to do that > > >>try to read the output myself? > >I would look around and see if someone already has code for this > >using libusb (which is fairly portable)... > > But wouldn't i still need some way of telling the kernel not to > attach the device? Like a quirk or disabling it via ukc like chriss > bennet suggested (and config -e for a more permanent solution). Or Yes you would, that would be a way to access it once it's attached to ugen. You can use config -e and disable uhid as long as you don't need it for your main keyboard. > can libusb tell the kernel to no longer handle the device? Unfortunately not. It would be useful (we could remove all these messy BAD_HID quirks...) but not possible at the moment. Some other OS allow libusb to talk to a device even though it's claimed by a driver, however that isn't really entirely safe. > >>I don't have the dmesg/attach info at hand, but will post it later if > >>required. > >> > >>Best regards Jens
