March 2006 - Wine-Devel - list.winehq.org

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Tony Lambregts

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

March 31, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Tom Spear

On 3/31/06, Augusto Arcoverde da Rocha <agarobr.listas(a)gmail.com> wrote: > > > On 3/31/06, Tom Spear <speeddymon(a)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

March 31, 2006

Re: Keyboard Rewrite

by Tom Spear

On 3/31/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > Am Freitag, 31. März 2006 21:33 schrieb Tom Spear: > > Hi all, this is a call for volunteers. I am hoping that certain > developers > > participating in another thread are willing to rewrite the keyboard > code, > > but we need people to test. If you are interested, please reply here > > saying that you are interested, and what kind of keyboard you use, as > well > > as the layout you use under X. I will be creating a wiki page for this > > project once the people who will be taking on this rewrite confirm that > > they will do so, and will post the link to this thread as soon as it is > > created. > > > > The purpose of this rewrite is to (hopefully) fix all of the problems > > people have with key mappings, characters not showing up as expected, > race > > conditions, characters not showing up at all, etc, and hopefully allow > us > > to close out many of the bugs in bugzilla having to do with the > keyboard. > > > > Thanks all in advance > > > > Tom > > If this is about testing, I'll gladly help. I use a German SUN Type6 > keyboard > (only one control key, Compose key, SUN keys instead of Windows keys, no > menu > key) with German layout and swapcaps. I also used to use an application > that > crashes due to a regression in Wine's keyboard handling it seems - could > be a > nice test app. > > -- > Willie Sippel > > //////// | Tritium Studios > // | ______________________________ > //// /// | http://www.tritium-studios.com > > <willie(a)froq.net> > > > Thank you all for your submissions. Please keep 'em coming. I am headed home now, and will organize all emails for this thread into a different folder on my machine so I can keep track of them. If some devs come forward and agree to start cracking on a keyboard rewrite, I will take my sorted emails and create the wiki page. I have the layout figured out in my head, but it is kinda hard to describe. You will see it in a few days, and I think you will like it. I do have a question for anyone who knows though. There are 2 distinct variations on the most common keyboard bugs. Keyboard output gets sent to console, or doesnt work at all; and these keys on my keyboard don't work or dont work as expected, or this layout isn't recognized by wine and wine said to report it here. Is the first variation a bug in the keyboard code, or is it something to do with some other component of wine? I ask because we already have a metabug in bugzilla, and I don't want to link those bugs to the metabug if they arent a bug in the keyboard code.. I'd rather link it to a directx metabug (if there is one) or so forth. Tom

March 31, 2006

Re: Update on Software Freedom Law Center work

by Kai Blin

* Alexandre Julliard <julliard(a)winehq.org> [31/03/06, 23:27:51]: > 2. Non-profit organization > > There are many advantages to having a non-profit organization for a > project, for instance to allow tax-exempt donations, or hold assets > like trademarks. However it's a lot of paperwork to do, so we never > went to the trouble of setting one up. > > Now the SFLC is starting an organization called the Software Freedom > Conservancy, that will be officially launched on Monday. It's > basically an umbrella non-profit that provides services to free > software projects. By joining that organization, we will get all the > advantages of having our own non-profit, without having to do any of > the work, so that seems like a good deal... > > There will also be the possibility of assigning our copyrights to that > organization, which would make it easier to enforce the license, and > provide some liability protection for developers. However this will > only be done if most developers are comfortable with it, so I'd be > interested to hear your feedback on this issue. I'm still unsure about this "assigning the copyright to someone else" thing. I'm living in the EU, where the copyright is split into "usage rights" and "creator's rights" and only the usage rights are transferable. I'm not into that legal stuff too much, so I'd leave that to experts to decide on, but I'd like to see a conclusive explanation on how this will apply to all of us new and old Europeans. Cheers, Kai -- Kai Blin, (blin at gmx dot net) I haven't lost my mind; I know exactly where I left it.

March 31, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Augusto Arcoverde da Rocha

> On 3/31/06, Tom Spear <speeddymon(a)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

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Chris Morgan

Just using the jack audio driver won't ensure that we won't see stuttering sound. If dsound is performing hardware emulation then it has its own internal thread that is performing mixing and other dsound events. If this thread gets held off then you'll have no sound to give to the jack audio drive when it runs. Increasing the size of this dsound buffer and ensuring that it runs seems like the easiest ways to fix issues with the dsound thread being held off and should work for all audio interfaces assuming their threads also run reliably. Chris On 3/31/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > Am Freitag, 31. März 2006 23:38 schrieb Mike Hearn: > > > Until it crashes your box of course... > > > > If a Windows program has a habit of hard freezing the system then the > > user will learn not to run that program. > > > > As it is, right now _many_ games suffer this problem with corrupted > > audio and it's very unpleasant (loud bursts of white noise). Makes the > > games unplayable, in fact. > > > > I'd rather make the games playable and give developers an incentive to > > find a better privilege model than leave this to coast along for another > > few years with only a bunch of talk, ideas and non-mainline patches. > > > > Right now there are no good solutions for this we can implement in Wine > > itself (except maybe making wineserver suid root and drop privs), and > > SCHED_ISO isn't merged into the mainline kernel, so telling users to > > upgrade won't solve much. > > > I'm probably wrong, but in theory, if Wine used the Jack audio driver, and > jackd is suid root, the sound shouldn't stutter but Wine/ a Windows app still > couldn't hard-lock the system, as Wine would run with standard user > privileges? If that's the case, wouldn't fixing the Jack driver and making it > the preferred output plugin solve the issue? I mean, it's at least as > conveniant as suggesting to run Wine as root... ;-) > > -- > Willie Sippel > > //////// | Tritium Studios > // | ______________________________ > //// /// | http://www.tritium-studios.com > > <willie(a)froq.net> > > >

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Willie Sippel

Am Freitag, 31. März 2006 23:38 schrieb Mike Hearn: > > Until it crashes your box of course... > > If a Windows program has a habit of hard freezing the system then the > user will learn not to run that program. > > As it is, right now _many_ games suffer this problem with corrupted > audio and it's very unpleasant (loud bursts of white noise). Makes the > games unplayable, in fact. > > I'd rather make the games playable and give developers an incentive to > find a better privilege model than leave this to coast along for another > few years with only a bunch of talk, ideas and non-mainline patches. > > Right now there are no good solutions for this we can implement in Wine > itself (except maybe making wineserver suid root and drop privs), and > SCHED_ISO isn't merged into the mainline kernel, so telling users to > upgrade won't solve much. > I'm probably wrong, but in theory, if Wine used the Jack audio driver, and jackd is suid root, the sound shouldn't stutter but Wine/ a Windows app still couldn't hard-lock the system, as Wine would run with standard user privileges? If that's the case, wouldn't fixing the Jack driver and making it the preferred output plugin solve the issue? I mean, it's at least as conveniant as suggesting to run Wine as root... ;-) -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Chris Morgan

Can't we use kernel capabilities to let people do this without having to run as root? Thats what jack audio server users are advised to do to ensure SCHED_FIFO. Chris On 3/31/06, Mike Hearn <mike(a)plan99.net> wrote: > > Until it crashes your box of course... > > If a Windows program has a habit of hard freezing the system then the > user will learn not to run that program. > > As it is, right now _many_ games suffer this problem with corrupted > audio and it's very unpleasant (loud bursts of white noise). Makes the > games unplayable, in fact. > > I'd rather make the games playable and give developers an incentive to > find a better privilege model than leave this to coast along for another > few years with only a bunch of talk, ideas and non-mainline patches. > > Right now there are no good solutions for this we can implement in Wine > itself (except maybe making wineserver suid root and drop privs), and > SCHED_ISO isn't merged into the mainline kernel, so telling users to > upgrade won't solve much. > > > If we have to require people to upgrade their kernel to get > > the feature that's fine; at least then when the box dies we can blame > > the kernel guys ;-) > > I agree that it's not good, but this patch makes the best of a bad > situation and it's better for the users this way. If they don't want to > run as root, they don't have to, and if - like me - they know the game > is safe and wish to have some fun this evening then they can. > > thanks -mike > > >

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Mike Hearn

> Until it crashes your box of course... If a Windows program has a habit of hard freezing the system then the user will learn not to run that program. As it is, right now _many_ games suffer this problem with corrupted audio and it's very unpleasant (loud bursts of white noise). Makes the games unplayable, in fact. I'd rather make the games playable and give developers an incentive to find a better privilege model than leave this to coast along for another few years with only a bunch of talk, ideas and non-mainline patches. Right now there are no good solutions for this we can implement in Wine itself (except maybe making wineserver suid root and drop privs), and SCHED_ISO isn't merged into the mainline kernel, so telling users to upgrade won't solve much. > If we have to require people to upgrade their kernel to get > the feature that's fine; at least then when the box dies we can blame > the kernel guys ;-) I agree that it's not good, but this patch makes the best of a bad situation and it's better for the users this way. If they don't want to run as root, they don't have to, and if - like me - they know the game is safe and wish to have some fun this evening then they can. thanks -mike

March 31, 2006

Re: Keyboard Rewrite

by Segin

Tom Spear wrote: > Hi all, this is a call for volunteers. I am hoping that certain > developers participating in another thread are willing to rewrite the > keyboard code, but we need people to test. If you are interested, > please reply here saying that you are interested, and what kind of > keyboard you use, as well as the layout you use under X. I will be > creating a wiki page for this project once the people who will be > taking on this rewrite confirm that they will do so, and will post the > link to this thread as soon as it is created. > > The purpose of this rewrite is to (hopefully) fix all of the problems > people have with key mappings, characters not showing up as expected, > race conditions, characters not showing up at all, etc, and hopefully > allow us to close out many of the bugs in bugzilla having to do with > the keyboard. > > Thanks all in advance > > Tom > >------------------------------------------------------------------------ > > > > Sure, I'll help. Let me go fetch my X settings... (opens nedit on /etc/X11/xorg.conf....) I don't know what this qualifies as, but it's 'hp5181' (my keyboard is a HP5181), The keyboard rules appear to be pc104 with extra code for extended keys, XF86Audio[InsetKeyHere], example, XF86AudioPlay (or whatever the name for it is, i know that XF86Audio part is right) My X config for the keyboard subject: Section "InputDevice" # miles of xorgcfg comments stripped for breverty, never removed them # ... Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "500 30" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) Option "XkbRules" "xorg" Option "XkbModel" "hp5181" Option "XkbLayout" "en_US" EndSection

March 31, 2006