October 2001 - Wine-Devel - list.winehq.org

Re: audio.c converted from WaitForSingleObject to poll

by Ove Kaaven

On Wed, 31 Oct 2001, Simon Britnell wrote: > 2) Removes the need to calculate a sleep interval in > the wodPlayer main loop, as it loops only when dsp is > ready to be written or a command is ready to be > received. Well, it seems like a bad idea to make the player thread enter a busy loop when there isn't enough data to fill the device buffers, don't you think? (Well, though I'd like buffer complete notifications to happen more frequently than they do in Wine's current implementation, making the player thread use 100% CPU isn't the way...)

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Gerard Patel

At 12:26 AM 31/10/2001 -0800, you wrote: > > Well, 0 is always wrong. So the previous code was always initializing >it to a wrong value. I was expecting descr.compression to be different >from BI_BITFIELDS which would give the expected 0xff0000, 0xff00 and >0xff. > What is the value of descr.compression? yes, it's 0 - big oops for me; I think I forgot to do a make at the top level :-(. Your patch is fixing the problem, thanks. Gerard

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Gerard Patel

At 05:50 PM 30/10/2001 -0800, you wrote: > > No no. Usually (0,0,0) means the default rgb layout. But if you >always go to asis in that case, then things will be wrong for users with >a bgr565 X configuration (should reverse in that case). > SetImageBits_* and GetImageBits_* should never get (0,0,0) as the >color masks. They don't know how to handle it and should not have to, >their callers are supposed to take care of that. > I think i found the source of the problem, some old code I had not >changed. Can you try the attached patch? I did and it does not change anything. I don't quite see how it could, since it does not seem better to not initialize data than initialize it to a wrong value :-) I tried ff0000/ff00/ff instead, with better success... Gerard

Oct. 31, 2001

Re:(no subject)

by Simon Britnell

--- Eric Pouech <eric.pouech(a)voila.fr> wrote: > you just need to make a windows handle from the unix > fd (the one of /dev/dsp) and do a > WaitOnMultipleObjects with 2 handles : > - the /dev/dsp handle > - the synchronization mechanism with all the wodXXX > functions. Didn't know I could do that. I do now :) Thanks for that. After my last post, I rampaged on ahead and converted audio.c to use poll, so that bit is now nice and unixish. I'm about to post the patch to wine-patch. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by François Gouget

Gerard Patel wrote: > > At 05:50 PM 30/10/2001 -0800, you wrote: > > > > No no. Usually (0,0,0) means the default rgb layout. But if you > >always go to asis in that case, then things will be wrong for users with > >a bgr565 X configuration (should reverse in that case). > > SetImageBits_* and GetImageBits_* should never get (0,0,0) as the > >color masks. They don't know how to handle it and should not have to, > >their callers are supposed to take care of that. > > I think i found the source of the problem, some old code I had not > >changed. Can you try the attached patch? > > I did and it does not change anything. I don't quite see how it could, > since it does not seem better to not initialize data than initialize it to > a wrong value :-) Well, 0 is always wrong. So the previous code was always initializing it to a wrong value. I was expecting descr.compression to be different from BI_BITFIELDS which would give the expected 0xff0000, 0xff00 and 0xff. What is the value of descr.compression? -- François Gouget fgouget(a)codeweavers.com

Oct. 31, 2001

Re:(no subject)

by Eric Pouech

> The idea is to have a (new) thread which does nothing > but sit in a select and then generate wine events > whenever the select returns. Various sound system > events cause /dev/dsp to be added to or removed from > the select list so that it generates a (new) > WINE_WM_DSP_READY event. my point is that you don't need an extra thread for that you just need to make a windows handle from the unix fd (the one of /dev/dsp) and do a WaitOnMultipleObjects with 2 handles : - the /dev/dsp handle - the synchronization mechanism with all the wodXXX functions. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

Oct. 31, 2001

double key events

by Arjen Nienhuis

I test wine often with a game called Elastomania. Wine gets better over the years, but there is one problem that remains when playing that game: In the menus the cursor moves two positons on a key press. The biggest problem is that most of the menus have an odd number of items, so half of them are not reachable. This happens with all the versions of wine I have tested on al the platforms I tested it on. The game uses directx. The problem is not in that both the keyup AND keydown events are being interpreted, because the cursor moves twice at keydown. The cursor does not repeat when a key is held down longer. My not so very usefull guess is that the program tries to shut down some sort of messaging, but that doesnt't work with wine, and the program still listens to those events, and recieves them. Where do keyboard events go? this is the output when ran with no cmdline options: Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40464254)->(00000000,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40386af8)->(00010021,00000013) fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:x11drv:X11DRV_DDHAL_CreatePalette stub err:dinput:SysKeyboardAImpl_Unacquire \ Unacquiring a not-acquired device !!! here is a summary of the output when ran with: --debugmsg +key,+keyboard,+dinput it starts with tons of: KEYBOARD_MapDeadKeysys no character for dead keysym 0x00XXXX and X11DRV_KEYBOARD_DetectLayout matches=47, mismatches=0, score=94 X11DRV_KEYBOARD_DetectLayout Attempting to match against "United Sta... blablabla... then: X11DRV_InitKeyboard fixme:ddraw:Main_DirectDraw_SetCooperativeLevel DirectInputCreateA IDirectInputAImpl_CreateDevice keyboarddev_create_device Creating a Keyboard device (0x40464288) then tons of: IDirectInputDevice2AImpl_SetDataFormat then: IDirectInputDevice2AImpl_SetCooperativeLevel \ (this=0x40464288,0x00010021,0x00000006) DISCL_FOREGROUND DISCL_NONEXCLUSIVE it then does very often: X11DRV_MapVirtualKey ... wMapType=1 and uses the return values in: GetAsyncKeyState () which is always: -> 0 and then (at line 25711)... X11DRV_KeyEvent state = 0 X11DRV_KeyEvent KeyPress : keysym=20 (space), ascii chars=1 / 20 / ' ' X11DRV_KeyEvent keycode 0x41 converted to vkey 0x20 X11DRV_KeyEvent bScan = 0x39. queue_kbd_event wParam=0020, lParam=00390001, InputKeyState=81 TranslateMessage (WM_KEYDOWN, 0020, 00390001) TranslateMessage Translating key VK_SPACE (0020), scancode 39 X11DRV_ToUnicode (0020, 0039) : faked state = 0 X11DRV_ToUnicode Found keycode 65 (0x41) X11DRV_ToUnicode Translating char 0x20 from code page 28591 to unicode X11DRV_ToUnicode ToUnicode about to return 1 with char 20 TranslateMessage 1 -> PostMessage(WM_CHAR) TranslateMessage (WM_CHAR, 0020, 00390001) I pressed the space bar! among 'failing' GetAsyncKeyStates is now GetAsyncKeyState (20) -> 8001 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 and then: X11DRV_KeyEvent state = 0 X11DRV_KeyEvent KeyRelease : keysym=20 (space), ascii chars=1 / 20 / ' ' X11DRV_KeyEvent keycode 0x41 converted to vkey 0x20 X11DRV_KeyEvent bScan = 0x39. queue_kbd_event wParam=0020, lParam=c0390001, InputKeyState=1 TranslateMessage (WM_KEYUP, 0020, C0390001) and yes: GetAsyncKeyState (20) -> 0 for the VK_UP that gets interpreted twice, the only diffrence is a call to X11DRV_ToUnicode that returns 0, so there is no: TranslateMessage (WM_CHAR... so for every keypress you get: ... GetAsyncKeyState -> 0 GetAsyncKeyState -> 0 keydown: X11DRV_KeyEvent queue_kbd_event TranslateMessage (WM_KEYDOWN... GetAsyncKeyState -> 8001 GetAsyncKeyState -> 8000 ... GetAsyncKeyState -> 8000 keyup: X11DRV_KeyEvent queue_kbd_event TranslateMessage (WM_KEYUP... GetAsyncKeyState -> 0 ... A demo of the game can be downloaded at http://www.elastomania.com

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by François Gouget

Gerard Patel wrote: > > At 01:06 AM 30/10/2001 -0800, you wrote: [...] > > Now I suspect that with your application the Dib masks don't look > >like the above > > Congratulations, you are entirely right. > As in many cases, Wine does not work because it is not tolerant > to strange parameters > > Actually the dib masks are all equal to 0. Probably the correct fix > is to assume an 'asis' (not reversed) conversion when the app does > not set any mask. No no. Usually (0,0,0) means the default rgb layout. But if you always go to asis in that case, then things will be wrong for users with a bgr565 X configuration (should reverse in that case). SetImageBits_* and GetImageBits_* should never get (0,0,0) as the color masks. They don't know how to handle it and should not have to, their callers are supposed to take care of that. I think i found the source of the problem, some old code I had not changed. Can you try the attached patch? -- François Gouget fgouget(a)codeweavers.com Index: graphics/x11drv/dib.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/dib.c,v retrieving revision 1.81 diff -u -r1.81 dib.c --- graphics/x11drv/dib.c 2001/10/17 19:41:54 1.81 +++ graphics/x11drv/dib.c 2001/10/31 00:21:04 @@ -4644,10 +4645,6 @@ break; case 24: - descr.rMask = descr.gMask = descr.bMask = 0; - descr.colorMap = 0; - break; - case 32: descr.rMask = (descr.compression == BI_BITFIELDS) ? *(DWORD *)info->bmiColors : 0xff0000; descr.gMask = (descr.compression == BI_BITFIELDS) ? *((DWORD *)info->bmiColors + 1) : 0x00ff00; @@ -4729,10 +4726,6 @@ break; case 24: - descr.rMask = descr.gMask = descr.bMask = 0; - descr.colorMap = 0; - break; - case 32: descr.rMask = (descr.compression == BI_BITFIELDS) ? *(DWORD *)info->bmiColors : 0xff0000; descr.gMask = (descr.compression == BI_BITFIELDS) ? *((DWORD *)info->bmiColors + 1) : 0x00ff00;

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Gerard Patel

At 01:06 AM 30/10/2001 -0800, you wrote: <snip lot of explanations> First thanks for all this stuff, really enlightening. > This probably means that you have a 16bpp rgb565 screen. Which seems >normal. It also means that the Dib is a bgr888 Dib which does not exist >in Windows. So something weird is happening. Here are the interesting >kind of lines: > >trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff >trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f > > This tells us that the Dib is a 24bpp dib and that it is an RGB dib, >the only kind of 24bit DIB in Windows. What tells us that it's an RGB >DIB is the r,g,b masks: the red color is encoded in the high bits of the >24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue, >0xff, hence the rgb888 shorthand. > Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you >will notice that the mask for the green color, 0x7e0, uses 6 bits >instead of just 5. This gives you the rgb565 denomination. > Finally we are in SetImage so we are converting the Dib into a Bmp, >i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis >(since both are rgb). > Now I suspect that with your application the Dib masks don't look >like the above Congratulations, you are entirely right. As in many cases, Wine does not work because it is not tolerant to strange parameters Actually the dib masks are all equal to 0. Probably the correct fix is to assume an 'asis' (not reversed) conversion when the app does not set any mask. Gerard

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Ove Kaaven

On Wed, 31 Oct 2001, Gerard Patel wrote: > Congratulations, you are entirely right. > As in many cases, Wine does not work because it is not tolerant > to strange parameters > > Actually the dib masks are all equal to 0. Probably the correct fix > is to assume an 'asis' (not reversed) conversion when the app does > not set any mask. You may want to find out where those masks are coming from first. For example, some of the DirectDraw code in Wine doesn't set the DIB masks properly for all bit depths.

Oct. 30, 2001