xpra icon
Bug tracker and wiki

#997 closed enhancement (fixed)

restore windows which were minimized during session lock on win32

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.17
Component: platforms Version: trunk
Keywords: win32 Cc:

Description

Follow up from #901:

  • we should keep track of the windows we minimized and restore them
  • we should not try to map new windows whilst the session is locked (or just minimize them immediately - and also restore those)

Attachments (1)

xpra997win32.txt (36.2 KB) - added by maxmylyn 16 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 20 months ago by Antoine Martin

Milestone: 1.00.17
Status: newassigned

comment:2 Changed 16 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

r12097 takes care of restoring the windows that were frozen during lock when the session is unlocked.
Not mapping new windows is harder, so I am moving this one to #1138.

Ready for testing.

comment:3 Changed 16 months ago by maxmylyn

Tested with the r12103 Win8.1 Client:

  • Windows restored properly after the lock
  • However, my display driver crashes every time (I saw this 3 times without any other applications open - Xpra is very much the obvious culprit) when I have OpenGL on.
    • As you may have guessed, it's an Intel Iris Pro iGPU. I'm sorry.
  • -d win32 not showing anything interesting, at least to me. I'll attach a .txt with the logs captured from the client anyway, you may pick up on something I don't.
  • HOWEVER: Xpra does not crash; just the display driver.

Changed 16 months ago by maxmylyn

Attachment: xpra997win32.txt added

comment:4 Changed 16 months ago by Antoine Martin

Owner: changed from alas to maxmylyn

HOWEVER: Xpra does not crash; just the display driver.


Intel drivers...

Still, r12152 may help: we now wait before deiconifying the windows.
The default delay is 1000 milliseconds, but you can change it with:

SET XPRA_DEICONIFY_DELAY=0
xpra_cmd attach ...

Let me know if any values help.
I would prefer if we found an event we can wait for instead of a delay (which may not work in all cases..), there may be one following the event we already use: WM_WTSSESSION_CHANGE: SESSION_UNLOCK on session 0x1, but since you got a crash instead, maybe it never got a chance to be seen. Running again with a higher delay may show something we can use in the log output.

comment:5 Changed 15 months ago by maxmylyn

@antoine: Need new Windows Beta Builds

comment:6 Changed 15 months ago by Antoine Martin

@maxmylyn: done!

FYI: there's another ticket for OSX which does something similar: #965.

comment:7 Changed 15 months ago by maxmylyn

Owner: changed from maxmylyn to Antoine Martin

Tried it a few times(half of Friday locking and unlocking, along with an hour this afternoon) with the r12161 client and it seems to be behaving for the time being. No more crashes or driver issues.

The default delay works fine. No real difference noticed when I set it to 0 or any other values (I tried 100,250,300,500).

Passing back to you.

comment:8 Changed 15 months ago by Antoine Martin

Owner: changed from Antoine Martin to maxmylyn

@maxmylyn: thanks for testing!
Since the zero-delay worked, I've changed the code in r12195 to make it better & cleaner, can you please re-test? (the XPRA_DEICONIFY_DELAY no longer exists)

comment:9 Changed 15 months ago by Antoine Martin

Somewhat related: ticket:540#comment:7

comment:10 Changed 15 months ago by maxmylyn

Owner: changed from maxmylyn to Antoine Martin

I retested this a couple weeks ago, and off and on since then and it is behaving pretty well. No more driver or Xpra crashes.

As of r12356 trunk client, it's still working. (Win81)

Passing back to you.

comment:11 Changed 15 months ago by Antoine Martin

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.