On Thu, 30 Mar 2006, Wine Bugs wrote:
http://bugs.winehq.org/show_bug.cgi?id=1181
------- Additional Comments From Speeddymon@gmail.com 2006-30-03 10:26 ------- Peter, I'm not sure if you ever did subscribe to wine-devel, but you did mention that wine could possibly reuse parts of your keysym implementation. Could you email the list (even if you dont scubscribe) and let them know about this bug, and see if anyone is willing to take a look at it. Just make sure you let them know you aren't subscribed, if you aren't, and to CC you on replies.
Hi, now you know about this bug. As the comment says, it might be possible to reuse some parts from the rdesktop implementation.
I'm not saying that it will be easy, though. To be honest, I think bug 4923, and many others, are more important. Instead of fixing Wine, it might be possible to enhance Xvnc so that it can "emulate" a physical Xserver with a certain physical keyboard.
Regards,
On 3/30/06, Peter Åstrand astrand@cendio.se wrote:
On Thu, 30 Mar 2006, Wine Bugs wrote:
http://bugs.winehq.org/show_bug.cgi?id=1181
------- Additional Comments From Speeddymon@gmail.com 2006-30-03 10:26 -------
[cut]
Hi, now you know about this bug. As the comment says, it might be possible to reuse some parts from the rdesktop implementation.
I'm not saying that it will be easy, though. To be honest, I think bug 4923, and many others, are more important. Instead of fixing Wine, it might be possible to enhance Xvnc so that it can "emulate" a physical Xserver with a certain physical keyboard.
I don't know the problem with the bug 4923 [1], but when we fix the bug 1181 [2] and make Wine use KeySym, this race condition won't occur since X11DRV_ToUnicodeEx function will not use AltGrMask or any other global variable concerning the keyboard state, only a table like "ksym2vkey". Besides, applications that use X server API directly don't have this behavior. --- [1] http://bugs.winehq.org/show_bug.cgi?id=4923 [2] http://bugs.winehq.org/show_bug.cgi?id=1181
I'm trying to solve the bug 2400 [3] and looking more closely the code in dlls/x11drv/keyboard.c I started thinking in rewriting this code to use directly keysyms sent by X server to translate XEvents to vkeys instead of the currently "xevent->keycode->keysym->keycode->vkey/character" way as implemented from the X11DRV_KeyEvent to X11DRV_ToUnicodeEx functions. --- [3] http://bugs.winehq.org/show_bug.cgi?id=2400
Regards,
Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00
Cheers, Augusto Arcoverde da Rocha
On 3/31/06, Augusto Arcoverde da Rocha agarobr.listas@gmail.com wrote:
On 3/30/06, Peter Åstrand astrand@cendio.se wrote:
On Thu, 30 Mar 2006, Wine Bugs wrote:
http://bugs.winehq.org/show_bug.cgi?id=1181
------- Additional Comments From Speeddymon@gmail.com 2006-30-03
10:26 ------- [cut] I don't know the problem with the bug 4923 [1], but when we fix the bug 1181 [2] and make Wine use KeySym, this race condition won't occur since X11DRV_ToUnicodeEx function will not use AltGrMask or any other global variable concerning the keyboard state, only a table like "ksym2vkey". Besides, applications that use X server API directly don't have this behavior.
[1] http://bugs.winehq.org/show_bug.cgi?id=4923 [2] http://bugs.winehq.org/show_bug.cgi?id=1181
I'm trying to solve the bug 2400 [3] and looking more closely the code in dlls/x11drv/keyboard.c I started thinking in rewriting this code to use directly keysyms sent by X server to translate XEvents to vkeys instead of the currently "xevent->keycode->keysym->keycode->vkey/character" way as implemented from the X11DRV_KeyEvent to X11DRV_ToUnicodeEx functions.
[3] http://bugs.winehq.org/show_bug.cgi?id=2400
I think that rewriting the keyboard code in this way is a very good thing,
and will be more than happy to help coordinate testing of it, although I can't test any myself. Rewriting the code should allow us to close many of the keyboard related bugs in bugzilla, which will be a big BIG plus in my book.
Like I said, if you want me to, I will coordinate testing of new code. I'll start a new thread called keyboard rewrite and ask for volunteers with different keyboard layouts to reply to that thread to test new code. I'm also going to create an offspring of the main wiki page for this project, once given confirmation that you will do the rewrite.
Tom
On 3/31/06, Tom Spear speeddymon@gmail.com wrote:
[cut]
I think that rewriting the keyboard code in this way is a very good thing, and will be more than happy to help coordinate testing of it, although I can't test any myself. Rewriting the code should allow us to close many of the keyboard related bugs in bugzilla, which will be a big BIG plus in my book.
Like I said, if you want me to, I will coordinate testing of new code. I'll start a new thread called keyboard rewrite and ask for volunteers with different keyboard layouts to reply to that thread to test new code. I'm also going to create an offspring of the main wiki page for this project, once given confirmation that you will do the rewrite.
Tom
Tom,
"I offer a hand and you grab my arm?" ;-) (in Portuguese this is a funny quote...)
I just said that I *started thinking* in rewriting the code, and I am still thinking... Nevertheless, I'm not an experience C programmer -- like many programmers in this list -- and I don't know the X server API and what vkey, keycode and keyscan mean until the last month when I tried to solve bug 2400 ("Issue with Delete when NumLock active").
I have looked at the rdesktop code and found an approach completely different of my ideas, a sign that I may be wrong (and probably am) about "keysym2vkey". :-/
If Wine Devel Community has no problem in putting this task on new hands -- even though I can dedicate full time to that task -- I also haven't got a problem! 8D
I will get very happy if some more programmers offer some *arms* (or some comments) to help me. :-)
But... I have a request... ;-)
Please apply the patch that I have sent to fix bug 2400 [1], because the <del> + <comma> key bug is too annoying ... and, at least, the problem is reduced until we can deliver a new keyboard driver.
--- [1] http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html
Cheers, Augusto Arcoverde da Rocha
On 3/31/06, Augusto Arcoverde da Rocha agarobr.listas@gmail.com wrote:
On 3/31/06, Tom Spear speeddymon@gmail.com wrote:
[cut]
I think that rewriting the keyboard code in this way is a very good
thing,
and will be more than happy to help coordinate testing of it, although I can't test any myself. Rewriting the code should allow us to close many
of
the keyboard related bugs in bugzilla, which will be a big BIG plus in
my
book.
Like I said, if you want me to, I will coordinate testing of new
code. I'll
start a new thread called keyboard rewrite and ask for volunteers with different keyboard layouts to reply to that thread to test new
code. I'm
also going to create an offspring of the main wiki page for this
project,
once given confirmation that you will do the rewrite.
Tom
Tom,
"I offer a hand and you grab my arm?" ;-) (in Portuguese this is a funny quote...)
Thats pretty funny even in english! lol Sorry if that is what I did.
I just said that I *started thinking* in rewriting the code, and I am
still thinking... Nevertheless, I'm not an experience C programmer -- like many programmers in this list -- and I don't know the X server API and what vkey, keycode and keyscan mean until the last month when I tried to solve bug 2400 ("Issue with Delete when NumLock active").
Yes I understand, which is why I said even if you can only contribute a little bit. I'm not expecting a complete rewrite overnight.. Heck, even Alexandre's window management rewrite has been ongoing for several months if not over the last year. I just figured that if you could do some of it, then other developers with more experience might take notice and start submitting patches, or might offer more tips on what is right and what needs to be changed about your patches..
I have looked at the rdesktop code and found an approach completely
different of my ideas, a sign that I may be wrong (and probably am) about "keysym2vkey". :-/
I see. Personally I think even if the approach is wrong, we could see the differences between it and our code and figure out what to do to make ours work like theirs does (100% all the time) without using the same approach (hope that makes sense)..
If Wine Devel Community has no problem in putting this task on new
hands -- even though I can dedicate full time to that task -- I also haven't got a problem! 8D
I'm sure that others will step up to the plate shortly. It has only been a couple of hours since I posted.
Hopefully nobody forces me to make this a call to arms for developers! ;-D
I will get very happy if some more programmers offer some *arms* (or
some comments) to help me. :-)
But... I have a request... ;-)
Please apply the patch that I have sent to fix bug 2400 [1], because the <del> + <comma> key bug is too annoying ... and, at least, the problem is reduced until we can deliver a new keyboard driver.
Alexandre? Can you comment please?
---
[1] http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html
Thanks so much guys
Tom
Augusto Arcoverde da Rocha wrote:
But... I have a request... ;-)
Please apply the patch that I have sent to fix bug 2400 [1], because the <del> + <comma> key bug is too annoying ... and, at least, the problem is reduced until we can deliver a new keyboard driver.
[1] http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html
This problem has been around for quite a while (since at least August 2004) I think it would be a good idea to apply this patch as well. This problem has been around for quite a while (since at least August 2004). It does what it is supposed to do and does not cause regressions. If it were up to me it would have been applied a while ago. However it is not up to me It is up to Alexandre.
Alexandre is there a reason that this patch is not acceptable for you?
--
Tony Lambregts
-
Augusto Arcoverde da Rocha -
Peter Åstrand -
Tom Spear -
Tony Lambregts