Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
Roderick Colenbrander wrote: > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote: >> Ok going through and looking at the next failure in wine tests I found this >> one : >> >> >> If you look at the code its: >> >> >> 779 color = getPixelColor(device, 160, 120); >> 780 red = (color & 0x00ff) >> 16; >> 781 green = (color & 0xff00) >> 8; >> 782 blue = (color & 0x00ff); >> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >> 784"DSTALPHA on frame buffer returned color 0x%08x, expected >> 0x00ff\n", color); >> >> >> but in MSDN it says : >> >> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >> >> Format of the rgb color is : >> >> 0x00bbggrr >> >> The low-order byte contains a value for the relative intensity of red, the >> second byte contains a value for green, and >> the third byte contains a value for blue. >> >> The high-order byte must be zero. >> >> The maximum value for a single byte is 0xFF. >> >> so shouldn't it be something like this: >> >>red = color & 0x00FF; >>green = ( color & 0xFF00 ) >> 8; >>blue = ( color & 0x00FF ) >> 16; >> >> not the what is in the test? because of the following C action >> >> expression1 >> shift_value >> >> Returns expression1 with its bits shifted to the right by the shift_value. >> The leftmost bits are replaced with zeros if >> the value is nonnegative or unsigned. This result is the integer part of >> expression1 divided by 2 raised to the power of >> shift_value. If expression1 is signed, then the result is implementation >> specific. >> >> so the test seems to be assigning the wrong values to the RGB Correct? >> >> chris >> > We are creating the framebuffer in the ARGB format (see init_d3d9). > D3D supports a variety of formats and we don't use the gdi RGB macro. > > Roderick > > Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it to come back in the ARGB format??? Is that setup in the init_d3d9? chris
Re: Garmin watches and USB
On 11/24/2009 10:58 PM, Stefan Dösinger wrote: Am 24.11.2009 um 22:43 schrieb Charles Davis: This really belongs on the wine-users mailing list. I'm not sure - I think from the context of the mail Chris is a coder himself, and the answer to his question on wine-users would be "Wine currently cannot do this". I am not too involved into the device mapping stuff in Wine, but I think what the app is missing is the enumeration of the USB device in the Windows USB services and/or the proper registry keys. Currently the only way to make the device accessible for Windows apps is doing something like ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1 Which gives you a classic serial port. But your app wants a USB-to-serial adapter with the right USB IDs etc. I think what is needed is an extension of the drive handling system that adds new drives when new disks are mounted to also add COM ports when serial ports appear, and add USB information when USB devices appear. I think this would be done somewhere in mountmgr.sys, but I am not sure. Maarten Lankhorst has written patches to get USB Storage devices listed properly a few years ago, in an attempt to make Windows Itunes sync to an Ipod. Those patches weren't committed because they need more work, but I think they would be a good starting point. Stefan, let me guess, you just wanted to point him to http://wiki.winehq.org/USB ? ;) bye michael
Re: Garmin watches and USB
Am 24.11.2009 um 22:43 schrieb Charles Davis: > This really belongs on the wine-users mailing list. I'm not sure - I think from the context of the mail Chris is a coder himself, and the answer to his question on wine-users would be "Wine currently cannot do this". I am not too involved into the device mapping stuff in Wine, but I think what the app is missing is the enumeration of the USB device in the Windows USB services and/or the proper registry keys. Currently the only way to make the device accessible for Windows apps is doing something like ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1 Which gives you a classic serial port. But your app wants a USB-to-serial adapter with the right USB IDs etc. I think what is needed is an extension of the drive handling system that adds new drives when new disks are mounted to also add COM ports when serial ports appear, and add USB information when USB devices appear. I think this would be done somewhere in mountmgr.sys, but I am not sure. Maarten Lankhorst has written patches to get USB Storage devices listed properly a few years ago, in an attempt to make Windows Itunes sync to an Ipod. Those patches weren't committed because they need more work, but I think they would be a good starting point.
Re: Garmin watches and USB
This really belongs on the wine-users mailing list. Chip
Garmin watches and USB
I'm trying to get the Garmin ANT Agent 2.2.7 to run (http://www8.garmin.com/fitness/ant_product_page.jsp). This software talks over the ANT+ protocol (carried over USB) to the watch, to download Heart Rate and GPS info. I cannot get the program to install because it checks that the ANT dongle is plugged in before it will complete installation, and it won't detect it. I also cannot debug this .exe using IDA very effectively because it is a self-extracting zip executable. When I plug in the ANT dongle, it is recognized by Linux and mapped to ttyUSB0. The dongle came with the watch and is Garmin branded, but it's really a Dynastream ANT2USB chip. Below is what /var/log/messages shows when I insert the device. Nov 22 15:23:27 desktop kernel: [1982277.092697] usb 4-1: reset full speed USB device using uhci_hcd and address 24 Nov 22 15:23:27 desktop kernel: [1982277.335442] cp210x 4-1:1.0: cp210x converter detected Nov 22 15:23:27 desktop kernel: [1982277.452593] usb 4-1: reset full speed USB device using uhci_hcd and address 24 Nov 22 15:23:27 desktop kernel: [1982277.610343] usb 4-1: cp210x converter now attached to ttyUSB0 I'm trying to figure out exactly what the installer is looking for to see if the dongle is present. I get a "You must connect your USB ANT Stick.." message in a dialogbox, and a Retry button. I thought it was checking for the presence of a new COM port or maybe something in the Windows device tree? I have installed the app on a Windows box, copied over the directory to Linux and run the program successfully under Wine. I do not know if it is communicating with the ttyUSB0 device though, I suspect it is not and I test that out tonight. On Windows, inserting the USB Dongle does not create a new COM port - so my guess is that the software is not treating this as a virtual COM port. If so using the old dosdevices file won't work. Any suggestions for either of these problems: - debugging a self extracting zip installer - getting a Windows app to use ttyUSB0 instead of whatever Windows USB device it would normally read/write from Thanks for any ideas, Chris
Re: Patch Tracker?
On Tue, Nov 24, 2009 at 3:22 PM, James Mckenzie wrote: > Austin English wrote: >>Sent: Nov 24, 2009 2:09 PM >>To: Nate Gallaher >>Cc: wine-devel@winehq.org >>Subject: Re: Patch Tracker? >> >>On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher >> wrote: >>> There's a new patch tracker? >> >>http://source.winehq.org/patches/ >> > Congratulations, Austin and Patch tracker team. I'm not involved, that was all Alexandre's doing. -- -Austin
Re: Patch Tracker?
Austin English wrote: >Sent: Nov 24, 2009 2:09 PM >To: Nate Gallaher >Cc: wine-devel@winehq.org >Subject: Re: Patch Tracker? > >On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher > wrote: >> There's a new patch tracker? > >http://source.winehq.org/patches/ > Congratulations, Austin and Patch tracker team. James McKenzie
Re: Patch Tracker?
On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher wrote: > There's a new patch tracker? http://source.winehq.org/patches/ -- -Austin
Re: Patch Tracker?
There's a new patch tracker? http://source.winehq.org/patches/ :) -- Owen Rudge http://www.owenrudge.net/
Re: Patch Tracker?
There's a new patch tracker? ~Nate Alexandre Julliard wrote: Folks, I'll be out for the rest of the week, so there won't be a release this Friday. 1.1.34 will be released on December 4. And with the new patch tracker you can watch the patches pile up while I'm away ;-)
Next release
Folks, I'll be out for the rest of the week, so there won't be a release this Friday. 1.1.34 will be released on December 4. And with the new patch tracker you can watch the patches pile up while I'm away ;-) -- Alexandre Julliard julli...@winehq.org
mapistub: add stubbed dll mapistub.dll
I guess we can forward those functions to mapi32 later on. While running the app, no functions were called at all, it was even enough to copy a random dll into system32 , and call it mapistub.dll. That was enough to get the app going
Re: ole32: Fix circular reference count in default handler objects.
2009/11/24 Rob Shearman : > This is caused by caching a pointer and reference to the data cache's > IPersistStorage interface without managing reference counts > appropriately. > --- > dlls/ole32/defaulthandler.c | 22 ++ > 1 files changed, 22 insertions(+), 0 deletions(-) > > Fixes memory leaks in defaulthandler tests. May also fix bugs 12419 & 14863. I should also note that the rules for aggregating objects implemented by this patch are listed here: http://msdn.microsoft.com/en-us/library/ms686558(VS.85).aspx -- Rob Shearman
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
I just realized something. The reason Wine doesn't respect LANG is that it overrides the LC_MESSAGES setting if it is set to the default. It will be set to the default if there is no LC_MESSAGES in the environment. So we don't want to override LC_MESSAGES if there's a LANG variable in the environment. Besides, why do all that work if we're not going to override LANG anyway if it's already set?
Re: wineserver: Mark registry hives clean after being loaded initially from file
Paul Chitescu writes: > @@ -1393,6 +1393,7 @@ > fprintf( stderr, "%s is not a valid registry file\n", filename ); > return; > } > +make_clean( key ); It would be better to create them with the correct flags in the first place. -- Alexandre Julliard julli...@winehq.org
Re: opengl32: fix wglCreateContextAttribsARB on nvidia
On Tue, Nov 24, 2009 at 9:10 AM, Dmitry Timoshkov wrote: > "Roderick Colenbrander" wrote: > >> +/* Nvidia converts win32 error codes to (0xc007 << 16) | win32_error_code >> */ >> +#define NVIDIA_HRESULT_FROM_WIN32(x) (HRESULT_FROM_WIN32(x) | 0x4000) > > Using MAKE_HRESULT() with appropriate severity and facility would be > cleaner IMO. > > -- > Dmitry. > I looked at MAKE_HRESULT and tried things like: MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, error_code) but this results in codes like 0x8007 because it only uses 1-bit for the severity level (where ntstatus codes use bit30 for severity and bit31 for error). I wasn't able to find a MAKE_NTSTATUS, so perhaps there is something else? Roderick
Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote: > Ok going through and looking at the next failure in wine tests I found this > one : > > > If you look at the code its: > > > 779 color = getPixelColor(device, 160, 120); > 780 red = (color & 0x00ff) >> 16; > 781 green = (color & 0xff00) >> 8; > 782 blue = (color & 0x00ff); > 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , > 784 "DSTALPHA on frame buffer returned color 0x%08x, expected > 0x00ff\n", color); > > > but in MSDN it says : > > This value is a 32-bit value used to specify an RGB color or CLR_INVALID > > Format of the rgb color is : > > 0x00bbggrr > > The low-order byte contains a value for the relative intensity of red, the > second byte contains a value for green, and > the third byte contains a value for blue. > > The high-order byte must be zero. > > The maximum value for a single byte is 0xFF. > > so shouldn't it be something like this: > > red = color & 0x00FF; > green = ( color & 0xFF00 ) >> 8; > blue = ( color & 0x00FF ) >> 16; > > not the what is in the test? because of the following C action > > expression1 >> shift_value > > Returns expression1 with its bits shifted to the right by the shift_value. > The leftmost bits are replaced with zeros if > the value is nonnegative or unsigned. This result is the integer part of > expression1 divided by 2 raised to the power of > shift_value. If expression1 is signed, then the result is implementation > specific. > > so the test seems to be assigning the wrong values to the RGB Correct? > > chris > We are creating the framebuffer in the ARGB format (see init_d3d9). D3D supports a variety of formats and we don't use the gdi RGB macro. Roderick
Re: mapistub: add stubbed dll mapistub.dll
2009/11/23 Louis Lenders : > This fixes http://bugs.winehq.org/show_bug.cgi?id=20050 > > The dll is present on my XP system This DLL is already partially implemented in a DLL called mapi32, so there should be no need to add this completely stubbed out. -- Rob Shearman
Re: opengl32: fix wglCreateContextAttribsARB on nvidia
"Roderick Colenbrander" wrote: +/* Nvidia converts win32 error codes to (0xc007 << 16) | win32_error_code */ +#define NVIDIA_HRESULT_FROM_WIN32(x) (HRESULT_FROM_WIN32(x) | 0x4000) Using MAKE_HRESULT() with appropriate severity and facility would be cleaner IMO. -- Dmitry.
