On 12/08/2010 17:07, Jon TURNEY wrote:
On 12/08/2010 16:49, Ryan Johnson wrote:
On 8/12/2010 5:46 PM, Jon TURNEY wrote:
On 10/08/2010 06:48, Ryan Johnson wrote:
On 8/10/2010 12:02 AM, Jon TURNEY wrote:
On 09/08/2010 22:14, Ryan Johnson wrote:
When I detached the monitor to leave the office, X disappeared with
signal 11
(log attached). Oddly, the log file didn't mention -resize as an
argument to
XWin, but it did attempt to resize so I assume the feature was active.
Oh dear. Well it seems I only thought I added code to only enable resize
support in multiwindow mode when requested, so it's always on for
multiwindow mode at the moment. That wouldn't be so bad, but it also seems
that the -resize code completely fails to correctly handle a change of
colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this
segfault.
Unfortunately, fixing this looks to be quite complex :-(
Thanks for testing, anyhow :-)
So... does that mean I have to roll back or face a seg fault after every
commute? Or is there a way to explicitly disable it?
I'm afraid so. As I say, I meant to add a means to disable -resize in
-multiwindow mode to avoid exactly this kind of situation.
Since it's the transition from 32bpp to 16bpp which breaks this, one possible
workaround would be to run your large monitor at 16bpp, which might also give
you working resize.
Okay, I think I have worked out the correct thing to do do to handle bpp
changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you
could try it and see if it works for you?
Note that you will need to use -resize with this build to turn on RANDR in any
mode.
If you can make this crash, with or without -resize, a backtrace would be very
helpful.
[1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
