1. Documentation is either incorrect or too vague: devices seem to work if Name option is set, but Device is not, but preinit fails; if both device and name are set device seems to be intialized twice: once as identifier, once as name 2. as preinit fails, keyboard is not setup correctly (don't know about mouse, but as it's standard, it works anyway), or rather it is, after I manually call setxkbmap (hal seems to be setup correctly) 3. while switching with Alt+Ctrl+Fn, Fn is transmitted to the active window
Forgot to add: all of this with xorg-server 1.4.0.90.
OK, point 2 is mostly invalid so I'll rephrase it. The problem I've had was that hal-setup-keymap was not called due to misconfiguration of hal. However, there's other problem, that can be related to this preinit stuff. Sometimes when I close X, when I drop to console keyboard mapping is not restored, meaning though keyboard worked correctly in X and worked correctly before startx it stops working correctly - it's mapping is messed up. If I switch to a different console (as Alt+Fn do work) and switch back correct keymapping is restored. And I noticed something strange in dosbox, while running X. While other programs seem to get correct keys, those run in dosbox do not. If I press Ctrl+F1, a mapping configuration is called and if I choose "Up arrow" and press it on the keyboard, it reports "Bind:Key Print Screen", "Left arrow" is "Key right alt". Probably there's more.
On Sun, Feb 10, 2008 at 03:41:53AM -0800, bugzilla-daemon@freedesktop.org wrote: > And I noticed something strange in dosbox, while running X. > While other programs seem to get correct keys, those run in dosbox do not. If I > press Ctrl+F1, a mapping configuration is called and if I choose "Up arrow" and > press it on the keyboard, it reports "Bind:Key Print Screen", "Left arrow" is > "Key right alt". Probably there's more. Sounds like dosbox either has a hardcoded keymap, or isn't reading the X keymap correctly.
(In reply to comment #0) > 1. Documentation is either incorrect or too vague: > devices seem to work if Name option is set, but Device is not, but preinit > fails; > if both device and name are set device seems to be intialized twice: once as > identifier, once as name man page has been updated recently, Name is not supported anymore (until somebody reimplements it).
renaming bug to reflect the remaining issue. Also, this is now a server issue.
I have to correct myself. Dosbox problem was indeed dosbox bug. Most of the problems were solved by adding AllowEmptyInput and removing Input sections of xorg.conf. And I think it's not the keymapping that gets broken, it's keyboard modifiers getting stuck, IOW though I have already released alt, keyboard acts like it's still pressed. And no it's definitely not a case of `keyboard keys getting stuck`, rather it's `keyboard modifiers state not properly restored`.
> --- Comment #6 from galtgendo@o2.pl 2008-05-09 02:38:17 PST --- > And I think it's not the keymapping that gets broken, it's keyboard modifiers > getting stuck, IOW though I have already released alt, keyboard acts like it's > still pressed. And no it's definitely not a case of `keyboard keys getting > stuck`, rather it's `keyboard modifiers state not properly restored`. > I think there's a fix for that in server-1.4-branch. Cheers, Julien
(In reply to comment #7) > > --- Comment #6 from galtgendo@o2.pl 2008-05-09 02:38:17 PST --- > > And I think it's not the keymapping that gets broken, it's keyboard modifiers > > getting stuck, IOW though I have already released alt, keyboard acts like it's > > still pressed. And no it's definitely not a case of `keyboard keys getting > > stuck`, rather it's `keyboard modifiers state not properly restored`. > > > I think there's a fix for that in server-1.4-branch. > > Cheers, > Julien Assuming this was fixed and closing this. Reopen if I'm wrong.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.