June 2012 - Wine-Devel - list.winehq.org

Re: comctl32: hotkey control needs to invalidate itself when painting for some apps

by Dmitry Timoshkov

Dan Kegel <dank(a)kegel.com> wrote: > @@ -190,6 +190,8 @@ HOTKEY_Paint(HOTKEY_INFO *infoPtr, HDC hdc) > HOTKEY_Refresh(infoPtr, hdc); > else { > PAINTSTRUCT ps; > + /* In some apps, the hotkey doesn't draw unless we invalidate it here */ > + InvalidateRect(infoPtr->hwndSelf, NULL, FALSE); It doesn't make sense to invalidate before painting in the paint handler. -- Dmitry.

June 18, 2012

Re: [PATCH] winepulse.drv: Add PulseAudio driver

by Chris Robinson

On Monday, June 18, 2012 11:18:45 AM Andrew Eikum wrote: > Is there any guarantee that Pulse /will/ give us a sufficient buffer? > From the API docs[1], it just "tries to assure" that we have the > requested buffer size, which actually means nothing. It "tries to assure that at least tlength bytes are always available in the per-stream server-side playback buffer". You get the buffer size you ask for with tlength, and the server does what it can to make sure that's how many bytes are waiting in the buffer (by sending write requests at the appropriate times to keep it filled, specifying the unused portion of the buffer as writable, etc). It doesn't mean the buffer itself can be smaller than what you asked for, just that the number of bytes waiting in it may be. The buffer size can increase up to maxlength, and that can be something like 2 or more seconds. > And even worse, Pulse's API doesn't let us set both the buffer size > and the latency[2]. The buffer size can grow as-needed, up to maxlength. The initial size won't restrict you in any way. If you set maxlength to -1, Pulse will set it to the max size supported by the server. There should be no issue with PulseAudio supporting buffer sizes as large as mmdevapi would want.

June 18, 2012

Re: comctl32: hotkey control needs to invalidate itself when painting for some apps

by Austin English

On Mon, Jun 18, 2012 at 11:14 AM, Dan Kegel <dank(a)kegel.com> wrote: > In at least one app, the hotkey control doesn't draw itself. > Invalidating its own window during HOTKEY_Paint gets the > control to draw properly, and makes the app happy. > > Fixes http://bugs.winehq.org/show_bug.cgi?id=30486 > (Unlike the patch attached to that bug, this one doesn't > also ask the background to be redrawn again.) > > > I think you meant to send this to wine-patches.. -- -Austin

June 18, 2012

comctl32: hotkey control needs to invalidate itself when painting for some apps

by Dan Kegel

In at least one app, the hotkey control doesn't draw itself. Invalidating its own window during HOTKEY_Paint gets the control to draw properly, and makes the app happy. Fixes http://bugs.winehq.org/show_bug.cgi?id=30486 (Unlike the patch attached to that bug, this one doesn't also ask the background to be redrawn again.)

June 18, 2012

Disabling joysticks with registry keys and joy.cpl

by Lucas Zawacki

Hello all, disabling an specific joystick device is an issue that is raised from time to time in this list. I'm planning on implementing it as a registry key like 'DirectInput/Disable controllername'. However I'd like the ability to disable specific joysticks on Linux, like the /dev/input/js* version, while keeping the /dev/input/event* one being enumerated. One option for doing this would be having a "Disable USB Controller" -> "driver" key with options being: "linux", "linuxinput", and "all". My only doubt is how would you guys want to have this option in joy.cpl? I think the correct thing to do would be to disable it with "all", but my use case includes a user disabling the repeated joysticks on Linux through the interface and if he's only able to disable all drivers at once that would be confusing and less useful. The bottom line is: can I add platform dependent code in joy.cpl for this purpose? If that's not an option, do you have some other way to do through joy.cpl or should it be registry only? Attached is an example patch of the approach for joystick_linuxinput.c Cheers, Lucas

June 18, 2012

Re: [PATCH] winepulse.drv: Add PulseAudio driver

by Andrew Eikum

On Mon, Jun 18, 2012 at 08:49:55AM -0700, Chris Robinson wrote: > On Monday, June 18, 2012 9:31:04 AM Andrew Eikum wrote: > > Yeah, I experimented with ADJUST_LATENCY, as it seems to be the trick > > to getting lower latencies. Then we have to maintain our own buffer, > > which is why I switched to using the write callback, to have Pulse > > tell us when it's ready for more data from our internal buffer. > > You shouldn't need a shadow buffer with ADJUST_LATENCY. Just write it to pulse > as the app writes it to mmdevapi. Why delay? It can handle the buffer sizes. > Are you sure? You said above: > Right, which is why you can't rely on what PulseAudio sets for the > buffer/tlength size... Is there any guarantee that Pulse /will/ give us a sufficient buffer? >From the API docs[1], it just "tries to assure" that we have the requested buffer size, which actually means nothing. And even worse, Pulse's API doesn't let us set both the buffer size and the latency[2]. Since we need to set the latency, we can't request a buffer size at all. So we have to rely on Pulse's default buffer size, and I don't think we can depend on that being sufficient in every single case and configuration. So we need the local buffer. > This also avoids the timing problems with the write callback. The most you'll > need is a temporary storage buffer for when an app writes an incomplete > period. > Yeah, the new design would only use the local buffer if not all of the data fed to mmdevapi will fit into the Pulse buffer. I remember trying this method and it failing for some reason, but maybe it'll work this time around. [1] At least, I think that's what the docs say. I still have no idea what these structure members actually do. <http://freedesktop.org/software/pulseaudio/doxygen/structpa__buffer__attr.h…> [2] <http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer…>

June 18, 2012

Re: windowscodecs: Create a IWICMetadataReader for a TIFF frame. Take 2.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > This looks better, but I still think you should use > WICPersistOptionNoCacheStream. > > Some of your failure cases in create_metadata_reader will return a > reference to an IWICMetadataReader, which seems wrong. Apparently that was a hasty attempt to make the patch appear in today's commit round. Sorry about that, I'll resend a fixed version tomorrow. -- Dmitry.

June 18, 2012

Re: [PATCH] winepulse.drv: Add PulseAudio driver

by Chris Robinson

On Monday, June 18, 2012 9:31:04 AM Andrew Eikum wrote: > We chatted a little on IRC this weekend, but thanks again for the > advice. No problem. :) > Mmdevapi sends it data to the lower systems in period-sized chunks, > and the reported buffer fill level decreases in period-sized chunks. > But the audio clock position is more accurate than that, returning > some value between periods, and taking into account latency. So the pulse driver would likely need a period-sized intermediary buffer, to store the unwritten samples that can't fill a full period (then keep it stored until enough writes are made to fill it and it's written to the stream). The PA_STREAM_INTERPOLATE_TIMING and PA_STREAM_AUTO_TIMING_UPDATE flags should provide timing with a good bit of granularity, along with regularly being resync'd to the server's clock. > Unfortunately, PulseAudio (and, apparently, every Linux audio API) > refuses to make any guarantees at all with regard to things like > buffer sizes, period sizes, callback regularity, and latencies. Right, which is why you can't rely on what PulseAudio sets for the buffer/tlength size, and you have to manage the expected size yourself, but that's easy. Luckilly PulseAudio supports buffer sizes up to about 2 seconds, I believe, which is good enough for mmdevapi. Unlike ALSA and others, Pulse has no problems handling buffers as large as what mmdevapi supports. PulseAudio doesn't really do periods. It actually disables audio hardware interrupts when it can and uses high-resolution timers to work out where the audio pointers are at any given time. The period values can pretty much just be emulated and neither pulseaudio or the app should care that much. Latency issues are what my approach tries to improve. Although ALSA's dmix still does perform better for playback, PulseAudio is at least now comparible and actually usable when it comes to responsive/interactive audio. For the callback regularity issues, keep in mind that you'll never get 100% guarantees with protected mode code on a multi-tasking OS, so as long as apps work as expected, it's "good enough". However, you can improve over Pulse's callbacks by using a background thread that keeps an eye on the amount of data pulseaudio has chewed through, and trigger any callbacks or events yourself as needed. > It'd be handy if there was some page explaining how PulseAudio's data > model works. Stuff like where the data is stored, when and how it's > transfered, when callbacks are triggered, what the members of > pa_buffer_attr actually mean (their documentation is useless), how the > stream flags affect stream operation and the callbacks, when the > buffer attributes might change and how applications should deal with > those changes. This stuff is all unclear to me, and I think it's a big > source of my frustration with the API. The sample data for playback streams is stored in the server, AFAIK. It's transfered when you call pa_stream_write, and it's either done synchronously or asynchronously depending on who "owns" the buffer it's given. With mmdevapi's design, there's no real problem to let pulse maintain ownership and do the writes asynchronously. Callbacks are triggered when the client receives the appropriate signals from the server. When exactly the server sends the signal depends on what the signal is and the various settings and attributes. PulseAudio's documentation isn't all that bad, considering. If you want to talk about bad API docs, look at ALSA. > Yeah, I experimented with ADJUST_LATENCY, as it seems to be the trick > to getting lower latencies. Then we have to maintain our own buffer, > which is why I switched to using the write callback, to have Pulse > tell us when it's ready for more data from our internal buffer. You shouldn't need a shadow buffer with ADJUST_LATENCY. Just write it to pulse as the app writes it to mmdevapi. Why delay? It can handle the buffer sizes. This also avoids the timing problems with the write callback. The most you'll need is a temporary storage buffer for when an app writes an incomplete period.

June 18, 2012

Re: windowscodecs: Create a IWICMetadataReader for a TIFF frame. Take 2.

by Vincent Povirk

This looks better, but I still think you should use WICPersistOptionNoCacheStream. Some of your failure cases in create_metadata_reader will return a reference to an IWICMetadataReader, which seems wrong.

June 18, 2012

Re: windowscodecs: Create a IWICMetadataReader when loading a TIFF frame.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Also, I just noticed that you're calling create_metadata_reader > > unconditionally from QueryInterface, and not checking in the process > > whether the reader has already been created. That will leak if QI is > > called multiple times. > > > > I'm not sure doing real work inside QueryInterface is a good idea. > > It's pretty surprising. > > > > I think it would make more sense to do this when a method on > > IWICMetadataBlockReader is first called, or in Initialize if > > WICDecodeMetadataCacheOnLoad is specified (though doing it in > > Initialize would require creating the frame objects then as well, and > > probably combining their refcounts with the parent). > > MSDN suggests different ways of creating a metadata reader: > 1. when creating a IWICBitmapFrameDecode > 2. when creating a block reader > 3. inside of GetReaderByIndex > > It's all up to an implementor. I decided to that at #1. Each instance > of IWICBitmapFrameDecode has its own metadata reader, I don't see how > it could be created twice or leaked. I take that back, thanks for the comments! -- Dmitry.

June 18, 2012