Wolfgang Klein staggered into the Black Sun and said: > I am using a usb keyboard which works well, as long as I use > Section "InputDevice" > Identifier "Keyboard1" > Driver "evdev" > Option "CoreKeyboard" > Option "Phys" "usb-0000:00:10.1-1/input0" > EndSection > > in xorg.conf. I'd like to get rid of the physical address there This is the first time I've seen the keyboard stanzas referring to a physical device. Then again, the kbd module has worked fine for me since 1999, and I don't know what additional functionality evdev could provide. > Option "Name" "HID 1267:0103" > instead, because the address changes when the keyboard is plugged off > an on again. Unfortunately, the name option doesn't work for the > keyboard. X crashes when I try this. > (EE) Keyboard1-usb-0000:00:10.1-1/input0: AbsoluteTouch: 'DIGI_Touch' > does not exist. Did you comment out the "Option "Phys" line? > I really did search a lot but I can't find any information on what > this "DIGI_Touch" thing is: is it a module for X11? Is it a kernel > module? Where do I find it? I have a feeling that it's the descriptor string obtained from something similar to lsusb. Reading the man page for evdev makes me wonder if something like this combination of options instead of what you have might help: Option "vendor" "1267" Option "product" "0103" ...the "Name" thing may be less robust than the raw vendor and product IDs. > Is there any other way to tell X which keyboard to use, regardless > [of] which port it is plugged into? For the longest time, X on Linux didn't *use* device files for keyboards. It just opened the tty where it was running. This is a newer thing and may have stupid problems--I know I've seen people complain about evdev before, though their complaints were qualitatively different from the problem you're having. -- So, what do *you* do for a living? I sit in a chair, pressing small plastic rectangles with my fingers while peering at many tiny, colored dots. --Peter Manders Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

Wolfgang Klein staggered into the Black Sun and said: > On 26.11.2007 at 13:33 (Dances With Crows) wrote: >> Did you comment out the "Option "Phys" line? > Yes, when I tried the "Name" option. Just making sure. >> Option "vendor" "1267" >> Option "product" "0103" > I tried that one as well: still the same error. Great. > Do you mean that it could be a bug in evdev because the product/vendor > id is misinterpreted? It's certainly a bug in evdev somewhere. libusb lets you access any USB device once you have the vendor and product IDs for that device, but evdev may not be using libusb and its methods for finding the device in the mess under /sys/ may not be entirely accurate. > Searching for the sentence "AbsoluteTouch: 'DIGI_Touch' does not exist" > one will find a lot of people who had the same error. > http://lists.freedesktop.org/archives/xorg-commit/2006-August/008615.html Yikes, that diff is huge. I tried to see which part of it was responsible for the problem and my eyes glazed over. >> For the longest time, X on Linux didn't *use* device files for >> keyboards. It just opened the tty where it was running. > I am running a multiseat machine, where two users use one computer at > the same time. Ah, a thing that not many people are doing. Generally, it's best to mention those things in the first message you post. I've heard of a number of ways to do that, but the earlier ones all talk about patching the kernel. One of the reasonably active people on col.misc, CptDondo, has set up a multi-seat machine recently IIRC. The main problem he had was with sound cards. It might be useful to post there and see what you can find out. > If I don't use the physical option above, one user will get two mice > and two keyboards and the other one will have none. It seems that the > first X server grabs all input devices it can find. Yes. That makes sense for single-user workstations, and most of the machines in use are single-user workstations or servers. > I'd like to get rid of this physical option, because if some other USB > device like the scanner or the camera is already plugged in while > booting, the USB devices can't be found any more. I don't know if this > is the fault of some buggy main board or of the OS. Argh. If evdev took device filenames (I don't think it does), it would be reasonably easy to put together a udev rule that linked /dev/input/eventN to /dev/input/kbd0 and /dev/input/eventM to /dev/input/kbd1 . But that is probably not an option. -- This is my rifle, this is my GNU This is for fighting, this is for $FOO! --AJS in ASR Matt G|There is no Darkness in Eternity/But only Light too dim for us to see