Bug 465541

Created attachment 319668 [details]
screenshot showing the "4 square" effect

This has an interesting effect on things like desktop backgrounds.  Attached is what happens to my background when I go from my 1280x800 laptop panel to my 1680x1050 LCD display.  This is a pretty visual regression :/

If you run gtk.main_iteration() in between the two calls to gtk.gdk.screen_width() you will get the right answer.

Did you test the above sequence on the beta? Because I don't think it will work there either.

(In reply to comment #2)
> If you run gtk.main_iteration() in between the two calls to
> gtk.gdk.screen_width() you will get the right answer.
> 

Yes that works, but only if done before calling gtk.gdk.screen_width() after the resolution change, see for example this sequence:

[hans@localhost ~]$ python
Python 2.5.1 (r251:54863, Jul 17 2008, 13:21:31) 
[GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> gtk.gdk.screen_width()
800
>>> gtk.gdk.screen_width()
800
>>> gtk.main_iteration()
True
>>> gtk.gdk.screen_width()
800
>>>

I did a "xrandr -s 1280x1024" (which worked) between the first and second gtk.gdk.screen_width(), notice how now even calling gtk.main_iteration() does not help anymore!

Anyways this clearly is a regression as this wasn't necessary before (and thus would break the promise of ABI stability).

I think that gtk.gdk.screen_width() (and height) need to pump the event loop / check the event queue for xrandr events themselves.

> Did you test the above sequence on the beta? Because I don't think it will work
> there either.

I didn't explicitly test it there, but this issue causes a problem in anaconda which AFAIK was not present in the beta (Note that we have a workaround in place for this now).

Assigning back to Matthias who can make decisions about pumping the event loop out of gdk_screen_width().

I don't see any justification for 'pumping the event loop' inside gdk_screen_width().

(In reply to comment #5)
> I don't see any justification for 'pumping the event loop' inside
> gdk_screen_width().

You mean any justification other them it returning the proper value? Well it returning the proper value seems like plenty of justification to me.

Connecting to GdkScreen::size-changed seems like the way to go.

When doing so, I notice that I get three emissions of the signal for each xrandr invokation. Not sure what thats about, but the last one gets the correct size.

> You mean any justification other them it returning the proper value? Well it
> returning the proper value seems like plenty of justification to me

Define 'correct' ? The correct value is the one gotten from the last processed
event. If you don't process events, the value doesn't get updated. Its the same for all other values that gtk gets via events from X.

From a quick investigation, it appears we are getting two 
XRRCrtcChangeNotify events for each xrandr call, the first one with
size 0, 0 and the second with the correct new size.

--> server problem

Well that's lame.  Can you give this build a try?

http://koji.fedoraproject.org/koji/taskinfo?taskID=894503

Includes a patch to coalesce randr state changes until the end of a request, which should eliminate any internal states we go through.  Of course if the 0x0 sizes are explicitly requested by the xrandr tool it won't help that much... in which case we'll want some kind of handshaking selection or something, blah.

Unfortunately, I sill see the extra crtc change notifies with width/height == 0/0

I also see 2 XRRScreenChangeNotify events, btw, one with the old size and one with the new.

The background resizing problem was fixed in eel2-2.24.1-3.fc10

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.