Hello
many distro ship the X-server with dinput2. More and more old games work pretty well now with Wine, but the mouse. Does anyone plan to work on the infamous bug 6971? It would be great if it could be implemented for the official release of Wine. It would do a big buzz :D
Cheers
David
On Thu, May 20, 2010 at 1:49 AM, David Adam david.adam.cnrs@gmail.com wrote:
Hello
many distro ship the X-server with dinput2. More and more old games work pretty well now with Wine, but the mouse. Does anyone plan to work on the infamous bug 6971? It would be great if it could be implemented for the official release of Wine. It would do a big buzz :D
Considering the code freeze starts tomorrow, I doubt a major architectural change will go in at this point, even if it could be written in time.
On 05/20/2010 12:49 AM, David Adam wrote:
Hello
many distro ship the X-server with dinput2. More and more old games work pretty well now with Wine, but the mouse. Does anyone plan to work on the infamous bug 6971?
If you talking about XI2 then see my notes about it in that bug. XI2 is unusable for what we need. Until that gets fixed we can't really use it.
Then comes the question on how intrusive do you want it? You can use latest patch from the bug with minor adjustments. But to make things really right, whole keyboard processing inside x11drv have to be rewritten.
Vitaliy.
On 05/20/2010 06:15 PM, Vitaliy Margolen wrote:
On 05/20/2010 12:49 AM, David Adam wrote:
Hello
many distro ship the X-server with dinput2. More and more old games work pretty well now with Wine, but the mouse. Does anyone plan to work on the infamous bug 6971?
If you talking about XI2 then see my notes about it in that bug. XI2 is unusable for what we need. Until that gets fixed we can't really use it.
Then comes the question on how intrusive do you want it? You can use latest patch from the bug with minor adjustments. But to make things really right, whole keyboard processing inside x11drv have to be rewritten.
By the way, you're not the only one who wants this. At the Ubuntu Developer Summit we talked about the need for ripping the keyboard code out of X entirely (and instead having it sit somewhere in the plumbing lair).
I'll admit I'm not too familiar with the details about why this is a good idea, but I believe it had something to do with keyboard layout issues for International users, especially in East Asia.
Do you know anyone who might want to work on this?
Thanks, Scott Ritchie
(Resending, on-list. Thanks, Gmail, apologies to Scott >_<)
On 21 May 2010 14:29, Scott Ritchie scott@open-vote.org wrote:
By the way, you're not the only one who wants this. At the Ubuntu Developer Summit we talked about the need for ripping the keyboard code out of X entirely (and instead having it sit somewhere in the plumbing lair).
I'll admit I'm not too familiar with the details about why this is a good idea, but I believe it had something to do with keyboard layout issues for International users, especially in East Asia.
Is there any particular documentation of this discussion or intention? I'm interested in the area, but I'm not clear on what's actually being discussed, change-wise.
On 05/21/2010 06:16 AM, Paul "TBBle" Hampson wrote:
(Resending, on-list. Thanks, Gmail, apologies to Scott >_<)
On 21 May 2010 14:29, Scott Ritchie scott@open-vote.org wrote:
By the way, you're not the only one who wants this. At the Ubuntu Developer Summit we talked about the need for ripping the keyboard code out of X entirely (and instead having it sit somewhere in the plumbing lair).
I'll admit I'm not too familiar with the details about why this is a good idea, but I believe it had something to do with keyboard layout issues for International users, especially in East Asia.
Is there any particular documentation of this discussion or intention? I'm interested in the area, but I'm not clear on what's actually being discussed, change-wise.
We didn't create a wiki page yet, but here are some copy/pasted Gobby notes taken during the session:
----- Current Situation: BIOS keyboard driver from boot to X - kernel replaces that with input drivers (can remap etc) - same drivers that X uses - atkbd translates scancodes to keycodes, X translates to key sequences - X starts up, uses /dev/input devices - on console currently have no way of differentiating keyboard
current X implementations: XKB (European) and XIM (Asian) compete with eachother - If you have a key on your keyboard to switch between US mode and "input mode" that can input other keys then we don't handle this well - A keyboard layout other than US English will leave you screwed if you're on an asian language - X sees keycodes rather than scancodes here - On X key swapping is done with the unique identifiers rather than scan codes - but the intermediate layer with unique key ids is not exposed - input method engine does not see intermediate layer - we need to know underlying layer as well - Thai problem: keyboard with a key to switch between US English and Thai layout - We have no indicator for what layout you're in, so Thai users tend to use only 0-9 for passwords because those characters are consistant between these two layouts - xkb doesn't support mapping one key to multiple unicode codepoints (such as for keys that actually generate two unicode characters)
Solution: rip out the mess in X, put everything in IBUS instead. - User Session IBus daemon running, X talks to it - xkeyboardconfig would need to be merged into IBUS - X would be happy to remove keyboard stuff so they can focus on Video instead - need someone to focus on the new bugs introduced by this change - Long term we will probably always have a display server (kernel will take video responsibility, remove VT layer) - udev keyboard config magic should be moved out (into device tree or uinput) - talk to xkeyboardconfig upstream and may be willing to help maintain it - Send Arne and Chris to X Conference and plead to the audience for someone to do this - Arne to gather help and get the facts right and prepare presentation - Chris to help Arne - Scott James Remnant to clarify how plumbing gets keycodes to X
----- If you have any questions you can ask ArneGoetje on Freenode (or mail him, here's his launchpad page: https://launchpad.net/~arnegoetje)
This is the kind of thing that should exist as a wiki page somewhere, so feel free to get started on one. I hope that helps, I'm not too knowledgeable on the subject myself.
Thanks, Scott Ritchie
Scott Ritchie scott@open-vote.org wrote:
current X implementations: XKB (European) and XIM (Asian) compete with eachother
That's not an issue, Windows has exactly the same problem just because asian languages keyboard support is very complicated, and other languages don't need that complexity (and huge slow down due to that).
- If you have a key on your keyboard to switch between US mode and
"input mode" that can input other keys then we don't handle this well
Then don't map the layout switcher keys to character keys :-)
- A keyboard layout other than US English will leave you screwed if
you're on an asian language
Not really, if your charset is UTF-8.
[skipped]
Solution: rip out the mess in X, put everything in IBUS instead.
- User Session IBus daemon running, X talks to it
- xkeyboardconfig would need to be merged into IBUS
- X would be happy to remove keyboard stuff so they can focus on Video
instead
Keyboard support can't be removed from X11 due to backwards compatibility and remote display support.
All this doesn't list the real problem with X11 keyboard layouts support - that a layout doesn't have a locale associated with it. So switching a keyboard layout would also switch the input locale. Of course, UTF-8 locale has been invented exactly to workaround that, so who cares... But if the input locale really existed in X11, UTF-8 would not be really needed.
UTF-8 charset introduced a lot of problems (it is multibyte -> needs very expensive handling/specially written applications which are multibyte aware, handling of multibyte strings is a lot more slower that single byte ones). RedHat bugzilla had a bug once UTF-8 has been introduced that grep worked 50 times slower in UTF-8 locale in comparison to simple en_US, but that bug has been happily closed fairly quickly without a fix.
-
Austin English -
David Adam -
Dmitry Timoshkov -
Paul "TBBle" Hampson -
Scott Ritchie -
Vitaliy Margolen