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

Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...

by Dimitrie O. Paun

On Mon, Mar 28, 2005 at 02:14:44PM +0200, Rein Klazes wrote: > Attached is a patch that solves Micha's scroll problem, also discussed > under bug #1091. It also does not change the handling of an existing > invalidated region. Nice, at least you nailed one :). As for the initial problem that I've reported (http://www.winehq.org/hypermail/wine-devel/2002/09/0748.html) you are correct, it's about interaction with the invalidated region. I've figured that while you have your hands wet in that code, maybe you can take a stab at it. Thanks for taking a look! -- Dimi.

March 28, 2005

Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...

by Rein Klazes

On Sun, 27 Mar 2005 11:34:12 -0500, you wrote: > On Fri, Mar 25, 2005 at 11:11:04AM -0600, Alexandre Julliard wrote: > > Modified files: > > windows : scroll.c > > dlls/x11drv : scroll.c > > dlls/user/tests: win.c msg.c > > > > Log message: > > Rein Klazes <wijn(a)wanadoo.nl> > > ScrollDC and X11DRV_SCROLLDC should scroll only pixels coming from > > within the visible region, clipped to the clipping region if that > > exists. Add the destination of pixels coming from the outside of this > > region to the update region. With tests that depend on this. > > > > Patch: http://cvs.winehq.org/patch.py?id=16854 > > Unfortunately, this patch doesn't fix bug 1091: > http://bugs.winehq.org/show_bug.cgi?id=1091 If I get this correctly, your bug#1091 has to do with scrolling a window that already has an invalidated region before the scroll. None of my patches would affect that (making your deduction more likely true). Attached is a patch that solves Micha's scroll problem, also discussed under bug #1091. It also does not change the handling of an existing invalidated region. Changelog: windows : scroll.c dlls/user/tests : msg.c ScrollWindow should call ScrollWindowEx with the SW_ERASE flag set. With conformance test. Rein.

March 28, 2005

Re: Wine device drivers proposal

by Damjan Jovanovic

--- Mike McCormack <mike(a)codeweavers.com> wrote: > > Damjan Jovanovic wrote: > > > I've been trying to add STI (still image) support > to > > Wine, and I've made some progress. However, I see > a > > deep and unsurmountable need to add (at least > > user-space) device drivers to Wine, and I would > like > > some feedback on these ideas. > > Drivers belong in the kernel. If there's no Linux > driver for a device, > then Wine cannot support it. In that case, the > first step is to write a > Linux device driver for it, which has the added > advantage that other > native linux applications can use the hardware. > > The interface from user space to kernel space should > be done via > standard Linux mechanisms, such as ioctl. The > Video4Linux API already > offers such an interface. > > You can't load a Windows driver that accesses > hardware in Wine, as Wine > is a user-space application with no I/O privileges. I am not trying to _load_ a Windows driver (that either requires kernel support for the Windows DDK, like ndiswrapper has, or emulation of an entire x86, like bochs does). What I am trying to do is _replace_ a Windows driver with equivalent libusb functionality, getting, in effect, something like this: Application (eg. the Gimp) | v special SANE backend | v SANE to TWAIN converter | v Windows user-space TWAIN driver (by manufacturer) | v STI | v Wine (with "drivers") | v Wine (user-space) driver | v libusb | v kernel > Mike Damjan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

March 28, 2005

Re: Dragon Naturally Speaking - working.

by Konstantin Goudkov

I got NS7 working on Debian Sid, after running Sidenet setup on Wine 20050310. It took me a while to figure out that I need to raise the Capture level, not just the Mic volume on ALSA. Without it, it looked like NS (and Wine) didn't not pick up the mic even though I could hear myself on the speakers. Also, sometimes not all buttons are clickable even through they should be, so try "Ctrl-S" during the user setup. -- Konstantin Goudkov

March 28, 2005

Re: Wine device drivers proposal

by Marcus Meissner

On Mon, Mar 28, 2005 at 07:52:48PM +0900, Mike McCormack wrote: > > Damjan Jovanovic wrote: > > >I've been trying to add STI (still image) support to > >Wine, and I've made some progress. However, I see a > >deep and unsurmountable need to add (at least > >user-space) device drivers to Wine, and I would like > >some feedback on these ideas. > > Drivers belong in the kernel. If there's no Linux driver for a device, > then Wine cannot support it. In that case, the first step is to write a > Linux device driver for it, which has the added advantage that other > native linux applications can use the hardware. > > The interface from user space to kernel space should be done via > standard Linux mechanisms, such as ioctl. The Video4Linux API already > offers such an interface. > > You can't load a Windows driver that accesses hardware in Wine, as Wine > is a user-space application with no I/O privileges. Actually for still imaging devices the Linux side uses libgphoto2, which is in userspace and uses libusb to access the kernel. I would really suggest to implement STI on top of libgphoto2 and try loading kernel drivers later. Ciao, Marcus

March 28, 2005

Re: Wine device drivers proposal

by Mike McCormack

Damjan Jovanovic wrote: > I've been trying to add STI (still image) support to > Wine, and I've made some progress. However, I see a > deep and unsurmountable need to add (at least > user-space) device drivers to Wine, and I would like > some feedback on these ideas. Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware. The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface. You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges. Mike

March 28, 2005

Re: Two small scrollbar fixes

by Alexandre Julliard

Rein Klazes <wijn(a)wanadoo.nl> writes: > dlls/user : scroll.c > dlls/user/tests : win.c > > - GetScrollRange should return an empty range, both upper and lower > limit zero, if the window has no scrollbars (msdn); > - GetScrollInfo's return value is FALSE if the window has no scrollbars; This breaks the message test: msg.c:2761: Test failed: GetScrollInfo error 5 msg.c:2761: Test failed: GetScrollInfo error 5 -- Alexandre Julliard julliard(a)winehq.org

March 28, 2005

Wine device drivers proposal

by Damjan Jovanovic

Hi I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Basically, many Windows device drivers are really trivial, but required for many apps. A scanner driver typically just accepts commands from a user-space app, does minimal processing, and forwards that to Windows. I've already hacked up Wine to get the same functionality, and it works - partially. I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver. The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() The problem is, how is a handle mapped to the appropriate driver? I've thought about it, and come up with 3 solutions. The first 3 don't require changes to the wineserver but aren't pretty. 1. Make the driver a true Linux kernel mode driver, and the handle its device file handle. Since ReadFile() and WriteFile() just do read() and write() system calls, this can be done. The problem is, DeviceIoControl() has to be implemented using ioctl(), and that's dangerous (sending the right codes to the wrong device can be catastrophic). Also, it's not portable to other OS's, and requires writing a kernel module (which isn't fun). 2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries. 3. KERNEL32.DLL and / or NTDLL.DLL keep their own handle table so they know which handles are driver handles and deal with those appropriately. Having to look up these tables for every call to ReadFile(), WriteFile() and DeviceIoControl() might be very inefficient, though. 4. Use an in-process solution, like a winelib DLL that has exports for dealing with ReadFile(), WriteFile() and DeviceIoControl(). This could be the most efficient, but then again, you need an efficient way to test a handle for being a driver handle, find the appropriate driver, and call the right exported function, which likely means the wineserver needs to have knowledge of these drivers and provide functionality for testing a handle for being a driver handle and have a way to find the driver. Let me know what you think. Bye Damjan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

March 28, 2005

Encoding PSP movies with Wine.

by Joshua Walker

Encoding PSP movies with wine. Well, the Sony Playstation Portable (PSP) is out in the U.S, and one of the cool things you can do with it is encode movies for playback on the system. Sony hasn't released their encoder yet, but you can use a program called ffmpeg to convert videos to the quirky PSP Mpeg4 format... ...kinda The Linux version of ffmpeg can encode PSP movies, however the id tag is hardcoded, and you don't get any data about the Name of the movie or it's length or anything. (It's just called "-" in the browser. You have to pull from the cvs version, the homepage is here... http://ffmpeg.sourceforge.net/index.php There is a Japanese fork of ffmpeg for win32. As it's GPLed software, the source was released. This includes all kinds of cool hacks for better streaming and also support for the ID tag for the PSP. Sadly, the id tags require Unicode, (As it's a Japanese machine) , and the hack involves a call to MultiByteToWideChar() to convert the title to something the PSP can display. Last night I tried to backport the hack to the Linux version using mbtowc() and failed horribly. My code-fu is much too weak. The Japanese fork is here http://www.nurs.or.jp/~calcium/3gpp/sources/ffmpeg-050310-0.30.tar.gz and a patch to update it to .31 http://www.nurs.or.jp/~calcium/3gpp/sources/ffmpeg_patched_diff_031.tar.gz You can also grab a compiled win32 version here. http://www.nurs.or.jp/~calcium/3gpp/3GP_Converter031.zip The program is located in the /cores dir. So, I as I couldn't "fix" the Linux version, I gave wine a spin and came up dead in the water. I'm afraid I don't have the debug version of wine installed, but here's what I can give you as output halkun(a)dokkun:~/temp/3GP_Converter031/cores> wine ./ffmpeg.exe fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please report !! err:comm:GetCommState tcgetattr or ioctl error 'Invalid argument' fixme:ntdll:NtQueryObject Unsupported information class 1 fixme:ntdll:NtQueryObject Unsupported information class 1 fixme:ntdll:NtQueryObject Unsupported information class 1 Segmentation fault halkun(a)dokkun:~/temp/3GP_Converter031/cores> Well, ending on a segfault is pretty much writes that program off the list. I'm also noticing it's calling an undocumented function in ntdll. Anyone want to take a go at this to see what's happening? It would be nice to get PSP encoding to work right under Linux. Oh, my version of wine is 20050310. -Halkun

March 28, 2005

Re: saving winrash

by Chris Morgan

Can we get winrash into the wine tree or is the plan to keep it separate? Chris On Friday 25 March 2005 1:16 pm, Robert Shearman wrote: > Chris Morgan wrote: > >>I have already sent links to documents on MSDN that state how to make a > >>service run on an interactive desktop. As some of the tests are a little > >>distracting graphically, we should probably do the dialog as you > >>suggest. I guess this is really up to the people running the test > >> machines. If the source to winrash was in the Wine tree I would already > >> have fixed it by now. > > > >The source has been available on Sourceforge since the project started. > >Patches welcome :-) > > Ah, ok. I've never seen a link to the project. Here's a patch that > should fix the creating of a service so that it appears on an > interactive window station. > > Rob

March 28, 2005