wine-devel April 2009

wine-devel@winehq.org

118 participants
279 discussions

Re: wined3d: don't update the screen when gdi back buffers are unlocked
by Stefan Dösinger 08 Apr '09

08 Apr '09

Am Mittwoch, 8. April 2009 17:12:01 schrieb Vincent Povirk: > This should fix bug 15789. > And he tells me that he's too busy to send the change in, and I should do > it if I want it to happen soon. Well, the main reason is that I don't have the games in question to test the patch myself. The same problem occurs in RealizePalette by the way. Otherwise the patch looks good to me

1 0

Re: wined3d: Use OpenGL vendor and renderer to pick driver and description.
by Roderick Colenbrander 08 Apr '09

08 Apr '09

Hi John, First of all this are basically two changes in one patch. Keep the vendor one separated from the device string. Second the opengl renderer string shouldn't be directly returned. In short d3d apps can query the pci id and opengl doesn't expose it (we aren't allowed to use /proc for card detection or so) and for that reason we 'estimate' what card is used based on the gpu capabilities (supported opengl extensions) and later on also the renderer string to refine the result a bit. For this reason the renderer string doesn't have to be the same as the pci id that we report. There are still some changes I have to make to the code and add a device string database. Roderick On Wed, Apr 8, 2009 at 8:40 AM, John Whitlock <John-Whitlock(a)ieee.org>wrote: > Use the OpenGL renderer for the device description > Use the OpenGL vendor to pick an appropriate XP device driver > Fixes bug 15839 > > The registry overrides seemed to make devs uncomfortable, so I'm trying > submitting without them. They are easy enough to add on top of this > change, > if the need arises in the future. > > > > >

3 2

Re: Added PulseAudio sound driver
by remi.assailly＠free.fr 08 Apr '09

08 Apr '09

Let's see. If distros include this driver, they >> This feature has been confirmed by popular vote at >> http://bugs.winehq.org/show_bug.cgi?id=10495 >They should stop voting for a redundant feature. Nobody submitted to wine-patches before, I prefer let Alexandre chose what he wants to do with it. > If they want to have it they should help make the patch *PERFECT*. That's about the only chance >the patch has to get in. So, while your work is not perfect but working you never try to submit it. Direct X support is not *PERFECT*, wine is not *PERFECT*, but you can use it and improve it.

1 0

Re: Added PulseAudio sound driver
by Marcus Meissner 08 Apr '09

08 Apr '09

On Wed, Apr 08, 2009 at 09:16:17PM +0200, remi.assailly(a)free.fr wrote: > Hi all, > > I'm submitting the PulseAudio patch from Arthur Talyor. > As most distros have PulseAudio by default Wine should provide upstream support. > Both Fedora and Mandriva have included this work and it is reported to work very well. > > I used latest patch from http://art.ified.ca/?page_id=40 > I just did a autoconf and autoheader. > > This feature has been confirmed by popular vote at http://bugs.winehq.org/show_bug.cgi?id=10495 The actual driver is missing. And split it into more pieces. (winecfg seperate for instance). Ciao, Marcus

1 0

Re: Added PulseAudio sound driver
by Nikolay Sivov 08 Apr '09

08 Apr '09

remi.assailly(a)free.fr wrote: > Hi all, > > I'm submitting the PulseAudio patch from Arthur Talyor. > As most distros have PulseAudio by default Wine should provide > upstream support. > Both Fedora and Mandriva have included this work and it is reported to > work very well. > > I used latest patch from http://art.ified.ca/?page_id=40 > I just did a autoconf and autoheader. > > This feature has been confirmed by popular vote at > http://bugs.winehq.org/show_bug.cgi?id=10495 > > Rémi > > Changelog : > added PulseAudio sound driver > Thanks to Arthur Talyor You've probably forgot to do "git add" for new files.

1 0

Re: [ 1/3] kernel32/tests: Add tests for GetVolumeInformationA and volume enumeration
by Alexandre Julliard 08 Apr '09

08 Apr '09

Guy Albertelli <galberte(a)neo.rr.com> writes: > BOOL found = FALSE; > > + buffer = VirtualAlloc( NULL, buflen, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE ); HeapAlloc is preferable. > + /* test the result of opening a volume id (no trailing \) */ > + /* this should work. It provides access to the disk volume */ > + /* starting with the first sector */ > + Volume[eos] = 0; > + hFile = CreateFileA( Volume, GENERIC_READ | GENERIC_WRITE, > + FILE_SHARE_READ | FILE_SHARE_WRITE, > + NULL, OPEN_EXISTING, > + FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING, NULL ); > + /* wine currently returns 5 (ERROR_ACCESS_DENIED) for normal */ > + /* volume ids (normal drive letters, ex C: -> ..\drive_c */ > + /* **cause: side effect of opening directory */ > + /* ** gets STATUS_INVALID_PARAMETER from NtCreateFile */ > + /* ** which comes from server(create_file) */ > + /* ** which comes from server(open_fd) because the open */ > + /* ** either open writable or readonly gives EISDIR. */ > + /* ** Then NtCreateFile returns status 0xC00000BA */ > + /* ** (STATUS_FILE_IS_A_DIRECTORY which is then */ > + /* ** changed to ERROR_ACCESS_DENIED */ > + /* The only time wine works is when the unix translation is a */ > + /* special file (ex: /dev/sdx). If that special device is */ > + /* readable (or r/w) for the user then the open succeeds. This */ > + /* allows the picture keychain to work if I set its permissions */ > + /* correctly. */ > + todo_wine ok(hFile != INVALID_HANDLE_VALUE && GetLastError() == ERROR_SUCCESS, > + "CreateFileA did not work, last error %u for device <%s> on volume <%s>\n", > + GetLastError(), Dev_Name, Volume ); This will fail on many Windows platforms too, you can't always open the raw device. And the tests are not the appropriate place for documenting Wine implementation details that are subject to change. > + if (ret) > + { > + trace( "First 64 bytes of volume <%s>, for device <%s>\n", > + Volume, Dev_Name ); > + dumpmem( buffer, 64 ); > + if (pGetVolumeInformationA) > + { > + /* need the traling \ for the API */ > + Volume[eos] = '\\'; > + ret = pGetVolumeInformationA(Volume, vol_name_buf, > + vol_name_size, NULL, NULL, NULL, fs_name_buf, > + fs_name_len); > + ok(ret, "GetVolumeInformationA failed, root=%s, last error %u\n", > + Volume, GetLastError()); > + if (ret && strcmp(fs_name_buf, "NTFS")==0) > + { > + /* If the filesystem is NTFS, then NTFS is in the */ > + /* first few bytes of the first block of the fs */ > + p = (char *)(buffer + 3); > + ok(strncmp(p, "NTFS", 4)==0, > + "NTFS file system does not match block read\n"); > + } This will probably never work on Wine, what's the point of that test? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: perform case-insensitive FOURCC comparison of built-in video codecs
by Dmitry Timoshkov 08 Apr '09

08 Apr '09

<Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > +#define compare_fourcc(fcc1, fcc2) (((fcc1)^(fcc2))&~0x20202020L) You ignore case even for mixed cased fourcc codes, but test only 2 cases: all lower/upper case codes, please test that cases too. -- Dmitry.

1 0

Loading of Mingw Provided .sys files
by Uwe Bonnes 08 Apr '09

08 Apr '09

Hello, trying to use the supplied or the mingw (cross) compiled libusb0.sys from sourceforge with the USB enabled tree from http://git.etersoft.ru/people/lav/packages/wine.git loading libusb0.sys fails: trace:winedevice:ServiceMain starting service L"libusb0" trace:winedevice:load_driver loading driver L"c:\\windows\\system32\\drivers\\libusb0.sys" trace:winedevice:load_driver_module name L"c:\\windows\\system32\\drivers\\libusb0.sys" module (nil) trace:winedevice:ServiceMain driver L"libusb0" failed to load trace:winedevice:ServiceMain service L"libusb0" stopped Using some other USB driver instead of libusb0.sys at least loads: trace:winedevice:load_driver loading driver L"c:\\windows\\system32\\drivers\\ezusb.sys" trace:winedevice:load_driver_module name L"c:\\windows\\system32\\drivers\\ezusb.sys" module 0x81340000 trace:winedevice:load_driver_module L"c:\\windows\\system32\\drivers\\ezusb.sys": relocating from 0x10000 to 0x81340000 trace:winedevice:load_driver_module name L"NTOSKRNL.EXE" module 0x84b70000 trace:winedevice:load_driver_module name L"HAL.DLL" module 0x84590000 trace:winedevice:load_driver_module name L"USBD.SYS" module 0x84580000 trace:winedevice:init_driver trace:winedevice:init_driver init done for L"libusb0" obj 0x84c0a560 The failure happens in program/winedevices/devices.c: static HMODULE load_driver_module( const WCHAR *name ) { IMAGE_NT_HEADERS *nt; const IMAGE_IMPORT_DESCRIPTOR *imports; size_t page_size = getpagesize(); int i, delta; ULONG size; --> HMODULE module = LoadLibraryW( name ); if (!module) return NULL; LoadLibraryW loads the file and then calls the DriverEntry of libusb0: NTSTATUS DDKAPI DriverEntry(DRIVER_OBJECT *driver_object, UNICODE_STRING *registry_path) { int i; DEBUG_MESSAGE("DriverEntry(): loading driver"); /* initialize global variables */ debug_level = LIBUSB_DEBUG_MSG; /* initialize the driver object's dispatch table */ for(i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) { driver_object->MajorFunction[i] = dispatch; } driver_object->DriverExtension->AddDevice = add_device; driver_object->DriverUnload = unload; return STATUS_SUCCESS; } While loading, the protection is set to 0014:trace:virtual:VIRTUAL_DumpView 0x68640000 - 0x68640fff c-r-- and driver_object is in the 0x68640000 pages and so writing to driver_object->MajorFunction[i] through an exception and the function fails. I guess libusb0.sys works on WIN32, so here our loader does something wrong or perhaps is not bug-to-bug compatible. Any fixes? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Re: win87em: always return that a 8087 coprocessor is present.
by Alexandre Julliard 08 Apr '09

08 Apr '09

Rein Klazes <wijn(a)online.nl> writes: > @@ -203,9 +203,9 @@ void WINAPI _fpMath( CONTEXT *context ) > context->Eax &= ~0xffff; /* set AX to 0 */ > break; > > - case 11: /* just returns the installed flag in DX:AX */ > + case 11: /* returns in ax whether a 8087 coprocessor is present, say yes */ > context->Edx &= ~0xffff; /* set DX to 0 */ > - context->Eax = (context->Eax & ~0xffff) | Installed; > + context->Eax = (context->Eax & ~0xffff) | 1; Should you set Installed to 1 instead? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/5] resend include: bring in6_addr into line with the MS definition
by Kai Blin 08 Apr '09

08 Apr '09

On Tuesday 07 April 2009 13:32:54 Jeff Latimer wrote: > The definition of in6_addr is not fully expanded as yet. This patch > adds the extra definition. This version is based on the Vista PSDK and > places the definition in in6addr.h. Is there any reason you're putting this into an extra header? The PSDK I have around keeps this in ws2ipdef.h Other than that, thanks. I've been working on a similar patch but got sidetracked. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 1

← Newer
1
...
20
21
22
23
24
25
26
27
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2009