WineHQ Bugzilla – Bug 29871 – drawing in photoshop cs5 is al...

launch photoshop cs5
open a new document (white background)
select the brush tool (black color for example)

try to draw something with the mouse.

most of the time, only the first click work, drawing the shape of the brush.
and sometime.. for whatever reason, you can draw something, as long as you keep the left mouse button pushed.

the problem is not only on the brush, but on every tool where you need to keep the left mouse button pushed.

this bug wasn't there in wine 1.3.28.

(In reply to comment #0)
> 
> this bug wasn't there in wine 1.3.28.

Please perform a regression test.

ok..
did my first ever regression test ^^ (using the tutorial)

in fact it was between wine 1.3.34 and 1.3.35
got this result :

cb3b7237925a24ba4c5696dd079fdc5d99a48577 is the first bad commit
commit cb3b7237925a24ba4c5696dd079fdc5d99a48577
Author: Alexandre Julliard <[email protected]>
Date:   Thu Dec 15 14:30:41 2011 +0100

    user32: Cache the global key state to avoid performance issues in applications that poll constantly.

:040000 040000 6fc9980517e631c9e7145313c1634713a36b11f4 dbc782b9be4295845ba663e5830b8114a67b290c M	dlls

*** Bug 30098 has been marked as a duplicate of this bug. ***

I can confirm, that the broken commit is cb3b7237925a24ba4c5696dd079fdc5d99a48577, like NaSH already found out.

Created attachment 39231 [details]
Patch for wine 1.4

Created attachment 39230 [details]
Patch to get photoshop painting

Since the bug made it in the 1.4 release, here a patch for it.

This patch will fix the behavior by disabling the caching of keys in
GetAsyncKeyState. This is just for the people who need Photoshop and a current
wine version and not any solution to the problem itself.

Since I never developed anything for wine, I couldn't figure up a good solution
to the bug, but hopefully the wine developers will fix it.

Confirming

*** Bug 30127 has been marked as a duplicate of this bug. ***

This one also affects UFO Extraterrestrials game, I had added a link to this bug to the game APPDB page.

tested today..

this bug still exist on wine 1.5.19

This bug still exists on wine 1.5.20.

Please, add Tim Roes's fix to the next wine release. Thank you.

add:

The problem is not only on the brush, but on every tool where you need to keep
the left mouse button pushed.

But with graphic tablet this bug doesn't occur, so I think it is connected only with mouse.

I can confirm it with wine 1.5.23

A workaround with Photoshop is to right click before performing a brush action.

Another problem with brushes.... have you tried to choose something different than these two boring types of brushes? For example "Round angle low stiffness" brush from the base set of brushes? Photoshop crashes. Every time. 
Wine 1.5.26, Ubuntu 64bit 13.04.

Affected also in the lastest dev (1.5.29). Can't wait this bug is fixed to move from CS2 to CS6, hope it will be done soon.

-------------------
@Mark W wrote:
A workaround with Photoshop is to right click before performing a brush action.
-------------------

Confirming this behavior (Photoshop CS6 + Wine 1.6-rc5). After right-clicking the brush tool works normally.

couldn't avoid the bug by right clicking, and having the brush tool working normally

anyway, it affect every brush tool in fact. eraser, corrector, duplicate stamp etc.. 

still present in wine 1.7.0

as a workaround (not tested) there's a ppa for ubuntu and a special version for a patched wine 1.5.30 requested on playonlinux (but still in the pipes)

but.. I worked with CS5 and wine1.6rcx for a month, with the only need of the atmlib.
thought the pblm was solved, but when i reset my workspace, the bug came back.

so, there might be something to set in photoshop to remove this bug. but i couldn't find it.

Ok guys its my first post for wine, and im french so, dont be to hard on me.

I tried the patch cause I had the same problem as you guys and I worked it out!!!

Im on ubuntu 13.04, and I had wine 1.6

So I did a manual compilation of wine, 

Started by downloading the 1.7 version here:

sourceforge.net/projects/wine/files/Source/

Then extracted wine in my home folder, 
and manually edited the file "wine-1.7.0/dlls/user32/input.c"
as shown in the patch (much easier than really patching i think)

then I apt-get installed all these dependencies because "sudo apt-get build-dep wine" didnt work for me:


    autotools-dev
    bison
    debhelper (>= 9)
    docbook-to-man
    docbook-utils
    docbook-xsl
    flex
    fontforge
    gcc-4.5
    gettext
    libasound2-dev
    libcapi20-dev
    libcups2-dev
    libdbus-1-dev
    libfontconfig1-dev
    libfreetype6-dev
    libgif-dev
    libgl1-mesa-dev
    libglu1-mesa-dev
    libgnutls-dev
    libgphoto2-2-dev
    libgsm1-dev
    libgstreamer-plugins-base0.10-dev
    libgstreamer0.10-dev
    libjpeg-dev
    liblcms1-dev
    libldap2-dev
    libmpg123-dev
    libncurses5-dev
    libopenal-dev
    libpng12-dev
    libsane-dev
    libssl-dev
    libtiff-dev
    libv4l-dev
    libx11-dev
    libxcomposite-dev
    libxcursor-dev
    libxext-dev
    libxi-dev
    libxinerama-dev
    libxml2-dev
    libxrandr-dev
    libxrender-dev
    libxslt1-dev
    libxt-dev
    libxxf86vm-dev
    linux-kernel-headers
    opencl-headers
    oss4-dev
    prelink
    unixodbc-dev
    x11proto-xinerama-dev

Finally I did the compilation:

./configure && make

And woohoo! 

./wine ~/photoshop.exe


This way i suppose you can get rid of this bug in any version of wine.

Cheers!

Could it be added to the official repository ? Like that this bug could definitly marked as "Fixed"

(In reply to comment #19)
No. As comment #5 explains, the patch is a hack that disables a Wine feature. Were it included in Wine, it would break other things.
As it is, a real solution has to be found. Regressions tend to be high priority for the devs though so this will be fixed eventually.

Hi man

How to copy patch input.c

(In reply to comment #20)
> No. As comment #5 explains, the patch is a hack that disables a Wine
> feature. Were it included in Wine, it would break other things.
> As it is, a real solution has to be found. Regressions tend to be high
> priority for the devs though so this will be fixed eventually.

I am sorry, but commit cb3b7237925a24ba4c5696dd079fdc5d99a48577 is still faulty:


Each thread has its own key cache that is used in dlls/user32/input.c:GetAsyncKeyState(.).
Unfortunately, Photoshop uses different threads to query the mouse button state when drawing.
I added printf() calls in GetAsyncKeyState to visualise this:
--8<--
(button 1 is pressed)
tkey 0x7ffd8044 <-- Thread 1
key 1: c1 (81)
-
tkey 0x81ed0044 <-- Thread 2
key 1: SHORTCUT 0, 79008969, 79008921 <---- WRONG
tkey 0x81ed0044
key 1: 81 (81) <-- Aha, button 1 still pressed
-
tkey 0x7ffd8044
key 1: 81 (81)
-
tkey 0x7ffd8044
key 1: 81 (81)
-
tkey 0x7ffd8044
key 1: 81 (81)
--8<--

To show this, I modified the function as follows:
--8<--
SHORT WINAPI DECLSPEC_HOTPATCH GetAsyncKeyState( INT key )
{
    struct user_thread_info *thread_info = get_user_thread_info();
    SHORT ret;

    if (key < 0 || key >= 256) return 0;

    check_for_events( QS_INPUT );

    printf("tkey %p\n", thread_info);
    if ((ret = USER_Driver->pGetAsyncKeyState( key )) == -1)
    {

        if (key == 1 && thread_info->key_state &&
            !(thread_info->key_state[key] & 0x80) &&
            GetTickCount() - thread_info->key_state_time < 50) {
            printf("key %d: SHORTCUT %x, %lu, %lu\n", (int) key, (int)thread_info->key_state[key], (unsigned long) GetTickCount(), thread_info->key_state_time);
            return 0;
         }

        if (!thread_info->key_state) thread_info->key_state = HeapAlloc( GetProcessHeap(), 0, 256 );

        ret = 0;
        SERVER_START_REQ( get_key_state )
        {
            req->tid = 0;
            req->key = key;
            if (thread_info->key_state) wine_server_set_reply( req, thread_info->key_state, 256 );
            if (!wine_server_call( req ))
            {
                if (reply->state & 0x40) ret |= 0x0001;
                if (reply->state & 0x80) ret |= 0x8000;
                thread_info->key_state_time = GetTickCount();
                printf("key %d: %x (%x)\n", (int) key, (int) reply->state, (int) thread_info->key_state[key]);
            }
        }
        SERVER_END_REQ;
    }
    printf("-\n");
    return ret;
}
--8<--

That's why Photoshop stops drawing the stroke right at the beginning: The second thrad is told that mouse button 1 is not pressed, because outdated data is cached by in the thread with thread info @0x81ed0044, while the drawing was initiated by another thread with thread_info @0x7ffd8044.

So, the mentioned commit is not thread-safe and breaks applications, like Photoshop.
Is it really more that a performance improvement for other apps?
What now? Revert the commit, admit that fixing the threading issue will reduce the benefit of the cache? ;-)

I am really interested in a solution that is acceptable for all.

In my opinion the whole key caching should be reverted again. Since you cannot blame this to be a bug or anyhow wrong implementation in Photoshop. It's just a bug in wine, and as Lucius already mentioned, making this thread safe might be not worth the performance benefit gained from the cache.

Even though you could say it affects only a hand full of applications, I think Photoshop is a pretty important application - important enough to through out buggy code (or at least fix it somehow).

Created attachment 47950 [details]
reverts commit cb3b7237925a24ba4c5696dd079fdc5d99a48577 on 1.7.15

Here's a patch that reverts broken commit cb3b7237925a24ba4c5696dd079fdc5d99a48577
It applies to wine 1.7.15.  Mouse drawing in Photoshop works great with this revert.

I can confirm that this bug affects Photoshop CS4, CS5 and CS6 in wine 1.7.15

It is quite sad because at least in my case this is the major blocker to being able to use Photoshop.

I would also vote for removing the faulty commit.

I forgot to add that this bug does not only prevent drawing, it prevents effective usage of any operation that depends on keeping the left mouse button pressed.

For example selecting stuff is quite hit and miss, and when trying to refine edges in CS5/CS6 this problem breaks the refining process as it makes mouse fine selection almost impossible.

Hi,

Can someone confirm or explain how this bug affects Perfect World?

If PW was added as affected in error could someone please remove it?

Thanks.

I made an account to add that I'm experiencing the same problem under Ubuntu 14.04 & Wine 1.6 (Manga Studio won't boot at all under 1.7).

I don't know if this is the right place to report this. I'm also having issue 18517.

*In Manga Studio 5. The app is missing from the list of those affected, that is.

Created attachment 49000 [details]
user32: Invalidate cached key_state whenever the state changes in one thread.

I don't have any of the affected applications, but based on the description in comment 22 this should fix it, while keeping the caching infrastructure in there.

Could you guys please test if this patch fixes the problem?

The behavior is different with this patch, but not improved.  I applied it to 1.7.22 (after adjusting it accordingly)

Instead of getting "dots" it now delays a second then lets you paint. The delay is too much to use. The mouse is also very slow now, just like when I use the stylus. Way too much calculating going on, and very little interactive performance. Try do paint a circle and you get an octagon. With your patch, it does the same thing for the mouse now.

I reverted back to my previous patch, posted in this thread, which reverts the whole commit that caused the initial bug, and it's behaving normal again with the regular mouse, but I continue to have stylus lagging so badly it's unusable. I have to use mouse-only until I get a fix for this.

I'm using photoshop cs6, Wine 1.7.22, a wacom Intuos 3, openGL mode (not directX)

If I check "Use Graphics Processor" in Photoshop prefs, I get garbled windows when opening a new or existing file. I'm using nvidia driver 331.43.
My K5000 card is identified fine, but I wonder if not using 3D could be causing slow stylus performance?


(In reply to Sebastian Lackner from comment #30)
> Created attachment 49000 [details]
> user32: Invalidate cached key_state whenever the state changes in one thread.
> 
> I don't have any of the affected applications, but based on the description
> in comment 22 this should fix it, while keeping the caching infrastructure
> in there.
> 
> Could you guys please test if this patch fixes the problem?

(In reply to Jay Hilliard from comment #31)
Just a note, I was getting corrupt graphics because of a line in my xorg.conf

Option "Composite" "Disable"

I thought it was fine because I had Composite disabled in favor of RGB overly mode.  Commenting it out solved the garbled graphics problem.  Go figure.

> If I check "Use Graphics Processor" in Photoshop prefs, I get garbled
> windows when opening a new or existing file. I'm using nvidia driver 331.43.
> My K5000 card is identified fine, but I wonder if not using 3D could be
> causing slow stylus performance?

the problem still occur on wine 1.7.35 on ubuntu 14.04.1

for a workaround
there's a patched version of wine if you use PlayonLinux.
the build named Wine1.7.20-PhotoshopBrushes
patched version 1.7.34-PhotoshopBrushes seems on the pipe, but not compiled at the moment.

I found a workaround in CS6.
I was able to draw properly after I disabled 'Spacing' for all the drawing tools.
After that, no more dots.

Not sure if this solution works on older releases of Photoshop.
Let me know if this helps.

Confirmed workaround ( wine 1.7.36 ) , although it does come with a change in behaviour

Many thx Max for this amazing workaround. No more needed to compile !

This regression affects the game Red Faction, but only when the Pure Faction 3.0 unofficial mod is installed (the base game is not affected).

The problem: only the first mouse click is registered in the menu (keyboard is working properly).

The patch from comment #30 does not fix the issue in the game.

Wine 1.7.38
Fedora 21
XOrg 1.16.3
XFCE 4.10

Someone can provide me a compiled version of wine patched for Photoshop please ? the workaround posted by Max is automaticaly desactived once I change the tool, so not a solution for me. Thanks in advance!

Thanks to Béla for providing a "more affordable" testcase (see https://bugs.wine-staging.com/show_bug.cgi?id=155). ;)

Relevant lines from the log:

--- snip ---
0028:fixme:msg:send_hardware_message validate keystate, state = 0x01
[...]
002b:trace:msg:peek_message calling mouse LL hook pos 453,195 data 0 flags 0 time 424441724 info 0
002b:trace:hook:call_hook calling hook 0xee040cbb WH_MOUSE_LL code 0 wp 201 lp 5e8e824 module L""
002b:Ret  hook proc 0xee040cbb (id=WH_MOUSE_LL,code=0,wp=00000201,lp=05e8e824) retval=00000000
002b:fixme:hook:call_hook invalidating key state
[...]
0028:trace:msg:peek_message got type 7 msg 201 (WM_LBUTTONDOWN) hwnd 0x2006c wp 1 lp 0
[...]
0028:Call user32.GetAsyncKeyState(00000001) ret=023a82c6
0028:fixme:win:GetAsyncKeyState cached = 0x01, wineserver = 0x80
--- snip ---

Invalidating the async key state in one thread should also invalidate it on other threads. This means my attempt earlier was almost right ... I only forgot a single line! :(

Will attach an updated patch shortly.

The updated version of the patch is available here:
https://github.com/wine-compholio/wine-staging/blob/master/patches/user32-Key_State/0001-user32-After-calling-LL-hooks-the-key-state-cache-ha.patch

Would be nice if someone could verify that it works with Photoshop CS5 too, to make sure that its really the same issue.

Created attachment 51219 [details]
Terminal output after the Tue, 7 Apr 2015 06:14:04 commit

For me, the bug is still present. Here is my terminal output. (Sorry if I don't know how to focus the bug in the log, so I posted it entirely).

Created attachment 51220 [details]
Screenshot of my attempt to draw 'WINE'

I've taken the 1.7.40 tarball and applied http://source.winehq.org/git/wine.git/commit/325c061bbd6fcd7ebaa60e62a69e52b000b61cdd and http://source.winehq.org/git/wine.git/commit/d3be42ab96cf8925bb2abd5c26b8ffa67c8b910c on top of it.

I still see the problem ( tested with Photoshop CS6 ) . I attached a screenshot of the results of my attempt to draw 'WINE'. This works apparently at random. 

Another strange situation is that if drawing a segment fails, the next attempt to draw produces a single dot at the location where the failed attempt started. You will see a number of these dots on my screenshot.

Robert, regarding your strange situation you're talking about in your last part, I think this is refered to the frame delay listed here : https://bugs.winehq.org/show_bug.cgi?id=33610

If you desactivate the hardware acceleration in CS6, this could work as workaround, waiting a fix for the original bug.

Artik: I did disable hardware accelaration now, and the behaviour is still broken but a bit more intuitive: the single dot appears once I press the mouse, so just the 'drag' doesn't work.

But the gist of it is: this bug isn't fixed for me either.

Ok, so the delay is workarounded. Simply download a fresh 1.7.40, and only patch it with https://bugs.winehq.org/attachment.cgi?id=39231&action=diff to fix the dot issue.

Hardware accel OFF, and you have a working Photoshop.

@Sebastian Lackner : if you want me to perform more tests, I'm here.

When Sebastian Lackner tried to fix this bug, the patch was no longer working. To get brushes working again, open /dlls/user32/input.c

Find and replace :

        if (key_state_info &&
            !(key_state_info->state[key] & 0xc0) &&
            key_state_info->counter == counter &&
            GetTickCount() - key_state_info->time < 50)
        {
            /* use cached value */
            return 0;
        }
        else if (!key_state_info)

By :
        
        /*
        if (key_state_info &&
            !(key_state_info->state[key] & 0xc0) &&
            key_state_info->counter == counter &&
            GetTickCount() - key_state_info->time < 50)
        {
            /* use cached value */
            return 0;
        }
        */
        if (!key_state_info)


(Sorry, don't know how to create a patch).

I just built wine from git (wine-1.7.47-161-g1a0c4ef) with the suggested patches here. The lagging which I thought was the driver, improved when I disabled "spacing" for the current brush.  Brush tab in photoshop -> Brush Tip Shape -> Spacing.  If I uncheck spacing I get a responsive pen with pressure sensitivity.
Note I can't fix the eraser spacing, so it continues to have the problem. I can't erase in a circle, it looks like a pentagon. It's still pretty much broken, as the function of "spacing" in photoshop is mandatory for us, so any help is appreciated in getting to the bottom of this.

Woohoo! I think I finally found the cause.

# xsetwacom --list
Wacom Intuos Pro M Finger touch 	id: 13	type: TOUCH     
Wacom Intuos Pro M Pen stylus   	id: 14	type: STYLUS    
Wacom Intuos Pro M Pen eraser   	id: 15	type: ERASER    
Wacom Intuos Pro M Pen cursor   	id: 16	type: CURSOR    
Wacom Intuos Pro M Pen pad      	id: 17	type: PAD       

# xsetwacom --get 14 all

Hmmm, why does my stylus have a TapTime of 250?

# xsetwacom --set 14 TapTime 0

Now photoshop painting is fluid and pressure sensitivity works. The previously mentioned brush-tip "spacing" option can use default settings now.

@JayHillard

So to make CS6 work with pressure and painting do I have to apply the patch and then change the wacomSettings?

Can you please provide detailed instructions, I don't want to go to WIN only for photoshop.

Thankyou

I had to do a few things.
Added the patch here for the dot problem. Modified slightly to work with wine 1.7.47 (git)
Added the patch to fix pressure sensitivity "final patch candidate" from https://bugs.winehq.org/show_bug.cgi?id=18517
Except not the context.c part of that patch which is already committed.
That's it. Build the patched wine and when you run photoshop, if you have a tablet with Touch, you will want to set TapTime for the stylus to 0 as noted in a my previous comment. If you don't set TapTime to 0 the stylus response will be so bad/slow it's unusable with the stylus.

There still exists an issue where when I paint multiple strokes quickly, say 5 time, 2 or 3 of the strokes will not have pressure sensitivity applied and they look very different. If you paint slower it works. I think it's something to do with the dot problem not being fixed "correctly" (cache issues between mouse and stylus?) or perhaps initial defaults for x,y,pressure shouldn't be 0xfffff, but rather be 0x0.
I don't know.  Any help appreciated.

(In reply to MNKYshield from comment #51)

I was able to work around this bug (the dot issue) by patching the evdev package with the debounce patch.
The problem went away just like that without disabling the cache as other patches in this bug do, So, debounce is masking the actual issue. It looks like we're getting a double click which causes the dot issue. I also noticed the first button activity (debugging wintab stylus button activity) shows the first packet with a non-zero value has a button value of 0. How can there be pressure with no button? so I wonder if that's causing it.  Could multiple mouse devs be passing the click?  Anyway, given that it can be fixed by patching evdev with debounce, perhaps we can implement debounce right in wine. The funny part is I have no need for the debounce patch outside of Wine/Photoshop. Linux apps don't seem to have this issue.

Hi Jay,
I have PshopCC working kinda smoothly under wine 1.8 on Kubuntu 15.10 but cant seem to patch evdev with debounce. I have evdev 2.9.2 and on compiling it gives an error referring to debounce.lo. The brushSetting panel shows pressure in the preview and there is no warning icon when setting Size to pressure. So I would like to test this with debounce, can you help, I have done some googling but no luck, Thanks.

Using wine 1.8 (from ubuntu PPA) and Photoshop CS 6 (13.0.1). Confirming that this bug persists.

I have tried both 32bit and 64bit versions, and have done the "right click" hack (corrects, though is tedious and will be tricky with my wacom) and also the "disable spacing" hack (also work, though rapid mouse movement creates a kinda "paint drop" effect)

Using wine 1.9.18 and Photoshop CS6. Bug still persist. But only brush, lasso and eraser tools not working so far.

*** Bug 41322 has been marked as a duplicate of this bug. ***

(In reply to illuslion1998 from comment #57)
> *** Bug 41322 has been marked as a duplicate of this bug. ***

Could someone refresh the title to include CS6 version too?

Open /dlls/user32/input.c

Find :
------------
        if (key_state_info &&
            !(key_state_info->state[key] & 0xc0) &&
            key_state_info->counter == counter &&
            GetTickCount() - key_state_info->time < 50)
        {
            /* use cached value */
            return 0;
        }
        else if (!key_state_info)
-----------------

and put a lower value than 50 for the line: 
GetTickCount() - key_state_info->time < 50)  
I put 10 so for me all is fine. Looks like this :
------------------------
        if (key_state_info &&
            !(key_state_info->state[key] & 0xc0) &&
            key_state_info->counter == counter &&
            GetTickCount() - key_state_info->time < 10)
        {
            /* use cached value */
            return 0;
        }
        else if (!key_state_info)
-------------------------
I tested in debug mode and he is using the cached value too and all is working good for me.

(In reply to Chituc Georgian from comment #59)
> Open /dlls/user32/input.c
> 
> Find :
> ------------
>         if (key_state_info &&
>             !(key_state_info->state[key] & 0xc0) &&
>             key_state_info->counter == counter &&
>             GetTickCount() - key_state_info->time < 50)
>         {
>             /* use cached value */
>             return 0;
>         }
>         else if (!key_state_info)
> -----------------
> 
> and put a lower value than 50 for the line: 
> GetTickCount() - key_state_info->time < 50)  
> I put 10 so for me all is fine. Looks like this :
> ------------------------
>         if (key_state_info &&
>             !(key_state_info->state[key] & 0xc0) &&
>             key_state_info->counter == counter &&
>             GetTickCount() - key_state_info->time < 10)
>         {
>             /* use cached value */
>             return 0;
>         }
>         else if (!key_state_info)
> -------------------------
> I tested in debug mode and he is using the cached value too and all is
> working good for me.

I tried, doesn't work for me, brush still dotted (lastest 1.9.19 git version).
Only https://bugs.winehq.org/show_bug.cgi?id=29871#c48 works for me.

(In reply to artik from comment #60)
> (In reply to Chituc Georgian from comment #59)
> > Open /dlls/user32/input.c
> > 
> > Find :
> > ------------
> >         if (key_state_info &&
> >             !(key_state_info->state[key] & 0xc0) &&
> >             key_state_info->counter == counter &&
> >             GetTickCount() - key_state_info->time < 50)
> >         {
> >             /* use cached value */
> >             return 0;
> >         }
> >         else if (!key_state_info)
> > -----------------
> > 
> > and put a lower value than 50 for the line: 
> > GetTickCount() - key_state_info->time < 50)  
> > I put 10 so for me all is fine. Looks like this :
> > ------------------------
> >         if (key_state_info &&
> >             !(key_state_info->state[key] & 0xc0) &&
> >             key_state_info->counter == counter &&
> >             GetTickCount() - key_state_info->time < 10)
> >         {
> >             /* use cached value */
> >             return 0;
> >         }
> >         else if (!key_state_info)
> > -------------------------
> > I tested in debug mode and he is using the cached value too and all is
> > working good for me.
> 
> I tried, doesn't work for me, brush still dotted (lastest 1.9.19 git
> version).
> Only https://bugs.winehq.org/show_bug.cgi?id=29871#c48 works for me.

Hello, 
Thank you for testing .
I tested this patch for the wine 1.8.4 , the one taht ships with the latest cedega version and for me is working perfectly for days .
I had to ajust the value to 5 finaly.
So the line looks like :
----------------
GetTickCount() - key_state_info->time < 5)
-----------------
I 'm only using the stable version of wine cause I use cedega .Maybe usefull for others . So remember I found the best is to put 5 , in palce of 50.
Have a good day all

To make the photoshop cs6 not to crash on startup ( it may crash randomly) I modifid the cedega shortcut command :

"/home/v/.cxoffice/Adobe_Photoshop_CS2/desktopdata/cxmenu/StartMenu.C^5E3A_users_Public_Start^2BMenu/Programs/Adobe+Photoshop+CS6.lnk" %u

to looks liek this :
-------------------------------------------------
#!/bin/sh
exec "/usr/bin/taskset" -c 0 "/opt/cxoffice/bin/wine" --bottle "Adobe_Photoshop_CS2" --check --wait-children --start "C:/users/Public/Start Menu/Programs/Adobe Photoshop CS6.lnk" "$@"
----------------------------------------------------------------
You notice "/usr/bin/taskset" -c 0  , it make photoshop just to use one cpu core.

I found this on google , and I put in my cedega too.

Also I pached wine 1.8.4 so the tool tips to do not steal focus on some dialog windwos like in 'Save For Web'. I will put patch here too maybe some othrs need i t.
I think wine developers do not have to much time to implement all patches submited from users on latest wine , but every user can patch his wine too.

To make tool tips not to steal focus on Photoshop Cs6 (and maybe others apps too)
I modified /dlls/user32/win.c .

//add this to your include
#include <string.h>
#include <stdio.h>
#include "commctrl.h"


//find this function
HWND WIN_CreateWindowEx( CREATESTRUCTW *cs, LPCWSTR className, HINSTANCE module, BOOL unicode )
{
    INT cx, cy, style, sw = SW_SHOW;
    LRESULT result;
    RECT rect;
    WND *wndPtr;
    HWND hwnd, parent, owner, top_child = 0;
    MDICREATESTRUCTW mdi_cs;
    CBT_CREATEWNDW cbtc;
    CREATESTRUCTW cbcs;

 
    ///////add this

    if (strcmp ( debugstr_w(className) ,debugstr_w(TOOLTIPS_CLASSW) ) == 0 )
    {
         cs->style = WS_POPUP;
         cs->dwExStyle = 0;
         /* This next line patch for some tools tips that do not dissapear from screen */
         if ( cs->hInstance == NULL ) 
            return 0;
    }
    /////////////////////

Created attachment 55828 [details]
Wine 1.8.4 (stable) patches for brushes and tool tips steal focus and not dissapearing

This is a patch for wine 1.8.4 stable , and fix the Brush Tool ,and fix the Tool Tips to do not steal focus ,and the tool tips that do not dissaper from screen

Created attachment 55829 [details]
This is a patch for wine 1.8.4 stable , and fix the Brush Tool ,and fix the Tool Tips to do not steal focus

This is a patch for wine 1.8.4 stable , and fix the Brush Tool ,and fix the Tool Tips to do not steal focus ,and the tool tips that do not dissaper from screen

The patch with the line reduced to 5 works well for me so far. Also, thank you for the tooltip focus stealing fix! That issue made working with cameraRAW impossible.

This fix cannot be pushed for the next releases ?

I think I have to patch myself all future wine versions too.
Wide developers said ,the win api can not contain special cases for tool tips .
But the only place I found where I can fix wine , was in SendMessage() .
So i do not know where they expect this fix to be implemented.
So if another developer will implement this fix a a way they consider is good , it will be fixed in the next wine versions . But I do not think they have time for this ,cause I see they focus more on games ,than on apps .
So for now I think I will have to patch myself the next versions of wine too.

Would anyone be interested in a PKGBUILD for the Arch Linux AUR that includes this patch? I just created one for my system for the latest stable WINE release (1.8.5) and could publish it if others would find it useful

Absolutely awesome patch Chituc Georgian! I applied it to Wine 1.9.21 and compiled the program on Arch Linux. Works as expected (Camera Raw etc.). Thank you.

I really wish this to be implemented into official builds. Steal focus issue and hovering tooltips have got to my nerves for years on Wine/Photoshop. I thought no one would ever fix these problems. Gladly I was wrong.

Build an Ubuntu biarch .deb would be amazing too ! :)

Thank you Fincer ,and I'm glad ppls find it usefull.
Since half year ago I found that Photoshop cs6 works on wine , and since then my desktop is Linux Mint.
I do not need windows if I have photoshop .
Tool Tips not working in photoshop seams streamge for me so I tried to see if I can do something .
I did not belive they made possible to work most of photoshop but forgot the tooltips .
As you can see the fix is easy to do , but the problem is , wine developers will probably not implement it in the main wine ,nor in 5 years from now . So I just wanted to help ppls who had same problem like me .I'm glad it works for you too.
Have a nice day !

After applying these patches, the brushes are now working as expected, but I still notice that palette windows get "stuck" above all other windows, e.g. if you switch from Photoshop to Chrome:
https://drive.google.com/file/d/0BzRZenNBDw6sbXFfOHJkcjU5cU0/view?usp=sharing

Is this fixed by the patches in this ticket, or is there another bug report for this issue (I couldn't find one)

This is another bug , I have it too .I keep the windwos attached to photoshop and all looks normal . maybe that will be fixed soon ...

Same problem here if I switch the workspaces.

http://i.imgur.com/2uhUyVW.png

Reporting it as a new bug would be a better option. Unfortunatly, it exists since years, but maybe never reported.

If you run : xwininfo  , in terminal , and click on that window , you will see it have a Override Redirect State: yes  . If there was a 'no' , the window will be ok . But it has a 'yes' so it preffer to be on top .Linux window manager do not manage this window ,it do not hide it etc , and becase photoshop do not hide it ,itself , that windows stay on top .

Is there a way in X to launch a program with Override Redirect State disabled? That would be fine with me

-----------------------------
Override redirect

Using override redirect is a kind of bazooka with bad side effects, and not at all a good idea if your goal is just to center a window.

If you set the override redirect flag when creating a window, then the window manager won't manage its size, position, stacking order, decorations, or map state (the window manager's redirection of ConfigureRequest and MapRequest is overridden).

This is a really bad idea for anything the user would think of as a window. It's usually used for tooltips and popup menus. If you set override redirect on a window, then all the normal window management UI will be broken, the stacking order will end up basically random (the window will tend to get stuck on top or on bottom, or worse get in an infinite-loop restack fight with another client).

----------------------------
If it is good just for tool tips and popup menus , why in photoshop wine give it to a real window ?

You can not dissable  Override Redirect for all wine windows , because if doing so , you will see on your app list , on your taskbar ,also some windows that belongs to a app but with a strange name , like "?" .If you want to play you can edit dlls/winex11.drv/window.c ,and make is_window_managed() always return true and see effects .

@Chituc Georgian

Yup. It's really helpful that someone who is capable of fixing issues gets some of the work finally done after these years of waiting. Personally, I'm fine with slight badly coding under the hood (Wine codebase) if nothing seriously breaks and the practical result is that I get rid of these annoying small bugs that have had negative impact on my daily workflow for years already.

For years I've been aware of the problem @Andrew Martin described above. I've got along with it by just docking the panels to the main program window and keeping the main window maximized. Sadly, this is not a proper solution and it's not very practical either.

There are even more issues related to windows/panels of Photoshop, such as buggy maximize & minimize behavior of the main Photoshop window (CC 2015 :: https://s21.postimg.org/7m2m99nuv/image.jpg) but that's another bug issue to be reported.

I m not a expert wine developer ,I just started to check the wine source last month ago . I m sure a expert wine developer can easily fix this problems but I also saw this problems persists over years and I tried to see if I can do something.I did some tests and I think the problem with photoshop panels will be fixed in about 1 month cause I M very busy with my job .I m optimist and I will share what I succed.

@Fincer   , here is a ugly fix implemented in wine that affects only photoshop .
it make the photoshop pannels to do not be on top ,over your existing windows.
Your pannels will appear on taskbar.So palette windows ,will not stay over the others linux windows .

You must edit dlls/user32/win.c  .

Find this function:

/***********************************************************************
 *           WIN_CreateWindowEx
 *
 * Implementation of CreateWindowEx().
 */
HWND WIN_CreateWindowEx( CREATESTRUCTW *cs, LPCWSTR className, HINSTANCE module, BOOL unicode )
{
    INT cx, cy, style, sw = SW_SHOW;
    LRESULT result;
    RECT rect;
    WND *wndPtr;
    HWND hwnd, parent, owner, top_child = 0;
    MDICREATESTRUCTW mdi_cs;
    CBT_CREATEWNDW cbtc;
    CREATESTRUCTW cbcs;

    ////add this
    if (strstr ( debugstr_w(className) , "OWL."  ) != NULL )
    {
 
    	if( ( cs->style & WS_POPUP ) && ( cs->style & WS_CLIPSIBLINGS ) && ( cs->style & WS_CLIPCHILDREN ) )
    	{
    		cs->style  = WS_POPUP | WS_SYSMENU  | WS_MINIMIZEBOX | WS_MAXIMIZEBOX ;

    		cs->dwExStyle |= WS_EX_TOPMOST;
    		
    	}
 

    }
////////////////////////////////////

Wine is strange , I could not fine something better for now ,but somebody maybe will made a generic fix that will work for all apps
Have a great day all!

Thanks! I applied your latest patch (comment 82) to Wine 1.9.21 and tested it on Photoshop CC 2015. Unfortunately, it seems to break tools panel (tool icons disappearing and reappearing immediately while moving cursor above them). See the pic below for details:

https://s9.postimg.org/nxbyqw3nz/photoshop_toolbar.jpg

I used this patch with tooltip fix patch you previously posted. I'm not sure if they conflict each other.

------------------------

Btw. All these issues, that have been discussed here, should be reported. However, we should stay on the topic ("drawing in photoshop is almost impossible") because, otherwise, this becomes nothing but bloated off-topic talking and the main issue will be overwhelmed by all unrelated messages.

They do not conflict , cause the tooltips patch affect just the windows created with a tooltip class .  

I 'm making tests so this panels fix ,is not yet a patch ,but it somehow works for photoshop cs6 .I will dig more ,and maybe other developer will make a better way too.

I made a separate bug report for the palette issue:
https://bugs.winehq.org/show_bug.cgi?id=41595

you can check this :

    if (strstr ( debugstr_w(className) , "OWL."  ) != NULL )
    {
 
    	if( ( cs->style & WS_POPUP ) && ( cs->style & WS_CLIPSIBLINGS )  )
    	{
    		cs->style  |=  WS_SYSMENU  ;

    		cs->dwExStyle |= WS_EX_TOOLWINDOW;
    		
    	}
 

    }

Is just for testing not a proper fix , but for cs 6 it works in  a way

@ Chituc Georgian

I just tested the latest patch you provided (comment 86) on Photoshop CC 2015. I guess it's better than the previous one (no missing/disappearing icons anymore). However, it creates another problem: if you undock tool/palette windows, they're drawn beneath/below the Photoshop main window. They are still present, but just one level below the main window so you can't practically interact with them.

@Chituc and others:
Stop the offtopic, if there are other bugs, file new bugs for them. It's getting hard to follow what is going on here, that hinders development! thx

@Sebastian: Can you send the staged patch to upstream please?

Tell yout mom top stop :)) THere was no talk for over a month here .Who do you see here talking?

(In reply to André H. from comment #88)
> @Sebastian: Can you send the staged patch to upstream please?

Have you tested that it works? The comments on this bug report are a bit misleading, so not sure if this a complete fix.

(In reply to Sebastian Lackner from comment #90)
> (In reply to André H. from comment #88)
> > @Sebastian: Can you send the staged patch to upstream please?
> 
> Have you tested that it works?

No, I thought it works because Michael made this bug staged.

(In reply to André H. from comment #88)
> @Chituc and others:
> Stop the offtopic, if there are other bugs, file new bugs for them. It's
> getting hard to follow what is going on here, that hinders development! thx
> 
> @Sebastian: Can you send the staged patch to upstream please?

You can chat on messanger ,your comments have to contribution :)

So for all around ,who come to this thread :

In this thread we FIXED a lot of problems , but most of the fixes will probably not be implemented soon in main wine git ,because for example wine devs say that wine API can not contain special cases for tooltips.
We made the fixes and we use the fixes cause make our live easier .
if will be or not integrated in wine , or ever fixed in main wine ,do not depend of us.
So if you need the fixes listed below you will probably have to integrate yourself and recompile wine .

-FIXED PHOTOSHOP TOP TIPS THAT STEAL FOCUS (works for other apps too)
-FIXED PHOTOSHOP WINE TOOL TIPS NOT DISSAPPEAR (works for other apps too)
-FIXED PHOTOSHOP BRUSH TOOL AND OTHER TOOLS THAT MUST TO DRAG WITH MOUSE
-FIXED MICROSOFT VISUAL C++ 6 CRASH WHEN CLOSE THE APP WHILE A MENU IS OPPENED
 
MADEE TESTS TO SEE WHY PHOTOSHOP PALLETS REMAIN ON SCREEN IF UNDOCKED FROM PHOTOSHOP AND FILLED ANOTHER BUG ABOUT THAT

Have a graeat day all!

(In reply to Chituc Georgian from comment #93)
> So for all around ,who come to this thread :
> 
> In this thread we FIXED a lot of problems , but most of the fixes will
> probably not be implemented soon in main wine git ,because for example wine
> devs say that wine API can not contain special cases for tooltips.
> We made the fixes and we use the fixes cause make our live easier .
> if will be or not integrated in wine , or ever fixed in main wine ,do not
> depend of us.
> So if you need the fixes listed below you will probably have to integrate
> yourself and recompile wine .

Wine only allows one issue per bug report. This bug is not about tooltip issues, only about the issue that drawing is difficult / impossible.

We did something ,not you who only chat . Have a good day ! I have to work!

(In reply to Chituc Georgian from comment #95)
> We did something ,not you who only chat . Have a good day ! I have to work!

Chituc, is there any way I could contact you? I'm willing to pay for some help.

I can confirm this bug with Wine 2.0-rc4 on Arch Linux (x86_64).

Phpotoshop CC 2015 with Wine Staging has similar issues. Also pressure does not work at all even though PS recognizes that my stylus is pressure enabled.

Is it the same bug, or I should open a separate ticket?

Sebastian, I can confirm that the original bug is fixed with the staged patch.
Please send it upstream.

(In reply to Huw Davies from comment #99)
> Sebastian, I can confirm that the original bug is fixed with the staged
> patch.
> Please send it upstream.

Wow! After 5 years, people depending on Photoshop for their work may be able to move to Linux finally?

I really hope this patch works and fixes CC too, it would be a huge breakthrough in Linux finally becoming a valid alternative for graphics professionals.

When I switched to linux Mint , I had minor problems with Photoshop , so that I started to work at some "patches" . 
Since then I never come back to windows .
Wine is great , Photoshop runs great with this patches.

In ubuntu 16.04 photoshop cc and cs5 i see problem with mouse. where you fix this problem?

Maybe the patch did not go into the main wine.You have to patch yourself and  recompile wine .

(In reply to comment #102)
> In ubuntu 16.04 photoshop cc and cs5 i see problem with mouse. where you fix
> this problem?

The bug status is STAGED → the fix is in wine-staging, but not yet in wine.

Nice work!!

This one thing was what was keeping me locked in on Mac. Fixing this might finally allow me to move to Linux.

Thanks for your work on this. :)

Closing bugs fixed in 3.0-rc3.

Removing the 2.0.x milestone from bugs included in 2.0.5.