#1050 closed defect (worksforme)
Portrait monitor full screen crashes tool
Reported by: | idlacrosseplayer | Owned by: | idlacrosseplayer |
---|---|---|---|
Priority: | major | Milestone: | 0.16 |
Component: | client | Version: | trunk |
Keywords: | crash | Cc: |
Description (last modified by )
Here are my system specs:
Host: RHEL WS 6.6
Client: Windows 7 x64
Monitor setup
3333 22222 3333 11111 22222 3333 11111 3333
Resolutions:
1) 1920x1080
2) 1920x1200
3) 1050x1680
Problem:
Whenever I maximize any application on Monitor 2, the xpra crashes. Other monitors can maximize as expected. I can manually strech to near the borders of monitor 2 without a crash.
I've attached my logfiles, and can do any further testing you need.
Attachments (5)
Change History (18)
Changed 5 years ago by
Attachment: | XORG55~1.LOG added |
---|
Changed 5 years ago by
comment:1 Changed 5 years ago by
Changed 5 years ago by
Attachment: | Capture.JPG added |
---|
Whitespace got trimmed in the text bug report. Image of monitor setup
comment:2 Changed 5 years ago by
Owner: | changed from Antoine Martin to idlacrosseplayer |
---|
Thanks for the logs, spotted this bug which will need fixing:
Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/xpra/x11/gtk_x11/wm.py", line 421, in do_child_configure_request_event log("do_child_configure_request_event(%s) value_mask=%s, forwarding to %s", event, configure_bits(event.value_mask), model) NameError: global name 'configure_bits' is not defined
There are also a number of client_decode_error: -1
, can you post the client output or log file? (found in APPDATA on win32)
As for the crash, it may just be that the window is too big, the "uh-oh" message is not fatal.
Is the second monitor the "primary" one for windows?
Do you have opengl enabled? Does it work if you disable it? Can you post the Opengl_check.exe
output?
comment:3 Changed 5 years ago by
comment:4 Changed 5 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from idlacrosseplayer to Antoine Martin |
Status: | new → assigned |
I have edited the ticket description to make it match the numbering in the picture above and prevent confusion.
I believe this isn't related to portrait orientation, but caused by having secondary monitors to the left of the primary one. (similar to ticket:636#comment:21)
comment:5 Changed 5 years ago by
comment:7 Changed 5 years ago by
Owner: | changed from Antoine Martin to idlacrosseplayer |
---|---|
Status: | assigned → new |
@idlacrosseplayer: your log file is full of opengl errors.
And I see that you are using this driver:
OpenGL enabled with Intel(R) HD Graphics 4000
opengl should not be enabled with the intel drivers, which are far too buggy. (there are many tickets on this tracker).
Can you please post the opengl output from the bug report tool, or simply post the OpenGL_check.exe
output?
comment:9 Changed 5 years ago by
OpenGL_check.exe output below. Is it related to the error? My laptop has a Quadro K1000M too. I'll have to check how to disable the Intel Adapter full time; I'll do that next.
C:\Program Files (x86)\Xpra>OpenGL_check.exe 2015-12-16 10:06:55,594 OpenGL_accelerate module loaded 2015-12-16 10:06:55,595 Using accelerated ArrayDatatype 2015-12-16 10:06:55,598 2015-12-16 10:06:55,599 2015-12-16 10:06:55,601 OpenGL properties: 2015-12-16 10:06:55,602 * GLU extensions : GL_EXT_bgra 2015-12-16 10:06:55,604 * GLU version : 1.2.2.0 Microsoft Corporation 2015-12-16 10:06:55,605 * display_mode : DOUBLE 2015-12-16 10:06:55,607 * gdkgl.version : 6.1 2015-12-16 10:06:55,608 * gdkglext.version : 1.2.0 2015-12-16 10:06:55,608 * gtkglext.version : 1.2.0 2015-12-16 10:06:55,609 * has_alpha : True 2015-12-16 10:06:55,611 * opengl : 3.3 2015-12-16 10:06:55,611 * pygdkglext.version : 1.0.0 2015-12-16 10:06:55,612 * pyopengl : 3.1.0 2015-12-16 10:06:55,615 * renderer : Intel(R) HD Graphics 4000 2015-12-16 10:06:55,617 * rgba : True 2015-12-16 10:06:55,618 * safe : True 2015-12-16 10:06:55,618 * shading language version : 3.30 - Intel Build 8.15.10.2712 2015-12-16 10:06:55,619 * texture-size-limit : 8192 2015-12-16 10:06:55,621 * vendor : Intel 2015-12-16 10:06:55,621 * zerocopy : True C:\Program Files (x86)\Xpra>
comment:10 Changed 5 years ago by
OK, I disabled access to the Intel HD drivers, and verified it in the OpenGL_check.exe.
I no longer crash when I try to maximize on the portrait monitor (3), however, when I maximize, it moves the window to my default monitor (1) and maximizes there.
I attached the new Xpra-Launcher.log after this.
New OpenGL_check.exe:
c:\Program Files (x86)\Xpra>OpenGL_check.exe 2015-12-16 10:16:05,134 OpenGL_accelerate module loaded 2015-12-16 10:16:05,134 Using accelerated ArrayDatatype 2015-12-16 10:16:05,150 2015-12-16 10:16:05,150 2015-12-16 10:16:05,150 OpenGL properties: 2015-12-16 10:16:05,150 * GLU extensions : GL_EXT_bgra 2015-12-16 10:16:05,150 * GLU version : 1.2.2.0 Microsoft Corporation 2015-12-16 10:16:05,150 * display_mode : DOUBLE 2015-12-16 10:16:05,150 * gdkgl.version : 6.1 2015-12-16 10:16:05,150 * gdkglext.version : 1.2.0 2015-12-16 10:16:05,150 * gtkglext.version : 1.2.0 2015-12-16 10:16:05,150 * has_alpha : False 2015-12-16 10:16:05,150 * opengl : 4.4 2015-12-16 10:16:05,150 * pygdkglext.version : 1.0.0 2015-12-16 10:16:05,150 * pyopengl : 3.1.0 2015-12-16 10:16:05,150 * renderer : Quadro K1000M/PCIe/SSE2 2015-12-16 10:16:05,150 * rgba : True 2015-12-16 10:16:05,150 * safe : True 2015-12-16 10:16:05,150 * shading language version : 4.40 NVIDIA via Cg compiler 2015-12-16 10:16:05,150 * texture-size-limit : 16384 2015-12-16 10:16:05,150 * vendor : NVIDIA Corporation 2015-12-16 10:16:05,150 * zerocopy : True c:\Program Files (x86)\Xpra>
Changed 5 years ago by
Attachment: | Xpra-Launcher.2.log added |
---|
Xpra-Launcher after I cannot maximize on center monitor (but no longer crash)
comment:11 Changed 5 years ago by
r11417 adds the "Intel" spelling to the greylisted drivers.
This will be included in the next stable updates and 0.16. Until then, I recommend you don't use the Intel GPU or turn off opengl.
I no longer crash when I try to maximize on the portrait monitor (3), however, when I maximize, it moves the window to my default monitor (1) and maximizes there.
How applications maxmimize varies widely based on the toolkit they use and how they actually implement it.
Which application can I use for testing?
(you may see more information by running Xpra_cmd.exe
with the -d metadata
flag)
I also spotted a new odd error in your log sample:
2015-12-15 10:51:20,924 error processing draw packet 2987 Traceback (most recent call last): 2988 File "xpra\client\ui_client_base.pyc", line 1989, in _draw_thread_loop File "xpra\client\ui_client_base.pyc", line 2035, in _do_draw File "xpra\client\client_window_base.pyc", line 426, in draw_region File "xpra\client\window_backing_base.pyc", line 496, in draw_region File "xpra\client\window_backing_base.pyc", line 233, in paint_image File "PIL\Image.pyc", line 682, in tobytes MemoryError
Not sure what to do with this one, as I've never seen it before.
comment:12 Changed 5 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
restarting the server (previously after disabling Intel and forcing NVIDIA, I had only restarted the client) fixed the "unable to maximize" from comment:10
The odd errors found in my logfile in comment:11 do not seem to affect normal operation, and I believe we can mark this as resolved/closed.
Thanks to everyone for helping!
comment:13 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1050
I think it has to do with this error in the logfile:
Uh-oh, our size doesn't fit window sizing constraints: 6449x8789 vs 6446x8787