[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora 8 internet keys support detailed plan + patches

On Thu, 21 Jun 2007 21:42:00 +0200
 Nicolas Mailhot <nicolas mailhot laposte net> 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
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

> 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

> 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



> -- 
> Nicolas Mailhot

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]