On Thu, 21 Jun 2007 21:42:00 +0200 Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > Hi Hans, > > Since I've been looking at the same stuff, and noticed > your post on > LKML, I was wondering when you were going to bring the > problem > Fedora-side. Here are my thoughts on the subject: > Thanks for sharing your thoughts with us, but I get the feeling you didn't look any further at my plan / proposal howto handle his for F-8, can you please provide some direct feedback on my proposal? Thanks! > 1. as mouse handling showed we're really better of with > the kernel > faking a single kind of device rather than exposing all > the device > quirks to userspace. Therefore input work should progress > from the > kernel upwards and not the current multi-layer approach > where efforts > somehow never meet in the middle > Agreed, the kernel should emulate a virtual ps/2 keyboard which always looks the same (with regards to scancodes) independend of the real keyboard. In the case of userspace using evdev then there is nothing to emulate though, as the kernel then directly exports all features of the hardware as it sees them. > 2. what should be emulated is a microsoft usb keyboard as > they're the > best specified and competition is forcing manufacturers > to target them > anyway > ?? I don't understand we do not "emulate" USB devices, the kernel emulates a ps/2 keyboard, because some (most) apps expect there to be a ps/2 keyboard, even though in reality a USB keyboard might be present. When the app uses the input devices instead of looking for a ps/2 keyboard, then there is no emulating, the apps directly gets all the event from the input device as the kernel sees them. Under certain circumstances the kernel may need configuration or bugfixing to properly see the event (for example to properly match ps/2 scancodes to its internal keycodes) but that is not emulating! Or are you talking about emulating a microsoft multimedia keys having ps/2 keyboard, in that case I gully agree, and so thus upstream as that is what they are already doing. > 3. however right now the kernel is not able to handle > latest microsoft > usb keyboards (google for hid bus on usb-devel). So first > effort > (getting target keyboard to work flawlessly to have a > reference) is > there. > There is no such thing as a target keyboard. With USB keyboards the hid standard clearly defines id's for every keys (see the hut 1.24 document) and the kernel maps these ID's to keycodes accordind to the hut standard. Microsofts keyboards are not relevant here the kernel follows the standard as it should, and since microsoft helps in writing this standard, I assume microsoft keyboards will implement it. > 4. Once that's fixed the only sane thing to target is > evdev. It's been > progressing quickly lately so putting efforts anywhere > else is insane. > Checking keyboard maps and app keybindings is a lot of > work, it would be > insane to do it for a temporary solution. > (everyone interested in testing should be careful to > restart his system > after reconfiguring X as you can get weird effects > otherwise). > Fedora currently is using the Xorg keyboard driver, not evdev. Since AFAIK there are no plans to change that for F-8 and I want to see this fixed before F-8, I don't think that switching to evdev is a good idea, too much work, too much chances for regressions, little short term gain. Internet keys can be made to work easily with the current xorg setup, with minimal chances and little work. So unless the xorg maintainer already wants to switch to evdev for F-8, this will not be needed for proper internet keys operation. > 5. the X internal keycodes are limited to 256 values, so > you can't just > assume a monster keyboard with every possible extended > key. More work > here. > AFAIK, no there not, they are sequences of 4 ASCII characters, so plenty of room. > 6. in an extended keys words some actions can be > triggered both by an > extended key and ctrl+foo combos so apps need to learn to > bind several > keybindings to a single action > Yes, no matter how e get X to send the correct X-keysyms for internet keys, we still need to fix the apps. So lets take a minimal effort approach to getting X to send the correct jeysyms and then focus on fixing the apps. > 7. manufacturers are often quite creative in the extended > key sets they > propose so users need to be able to remap them > (optionaly, as some users > will take what's printed on keys over anything else, even > if what's > printed is totally useless) > ??? I don;t understand if the key comes with a finding glass icon, and X sends XF86Search as keysym, then all is well, if the user wants to binf this keysym to something other then search, thats fine, just like the user can make the 'a' key always launch an xterm when pressed. IOW, what does this have todo with anything? > 8. lots of usb gadgets have extended keys nowadays, not > just keyboards > so the remapping & keybindings apps need to learn to be > less > keyboard-oriented someday > Thats a far, far away future, when X will support plug and play of input devices and thus actually will be able to differentiate between the laptop keyboard and the just pluged in usb keyboard. As long as X cannot differentiate between these, there is nothing we can do to make the apps see the difference. > 9. laptops are not the only ones with extended keys, and > dmi is a > laptop-specific solution > I agree, actually isn't that exactly what I wrote?? > That's a lot of stuff to fix, and it won't happen > overnight, so a > short-term target should probably be to choose a > reference keyboard, > enable evdev and try to have all our test hardware behave > as well as it > in this mode (well ≠ perfect as we're not there yet > unfortunately) > Why enable evdev? Thats lots of work + many potential problems without much gain, Please read my proposal, which is meant as a solution which can be implemented in a short time, with a small it of (nearly finished) work on the xkb side, and most work on configuring apps, which is work which we can reuse if we decide to evdev, or input system X later. Regards, Hans > -- > Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
