Bug 465541 - gtk.gdk.screen_width() no longer gets updates for xrandr changes
gtk.gdk.screen_width() no longer gets updates for xrandr changes
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: fedora-x-target
  Show dependency treegraph
 
Reported: 2008-10-03 15:38 EDT by Hans de Goede
Modified: 2013-01-09 23:49 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:29:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot showing the "4 square" effect (1.36 MB, image/png)
2008-10-07 12:57 EDT, Jesse Keating
no flags Details

  None (edit)
Description Hans de Goede 2008-10-03 15:38:11 EDT
Best described with reproduction instructions:
Terminal 1:
python
>>> import gtk
>>> gtk.gdk.screen_width()
1280
>>>
Terminal 2:
xrandr -s 800x600
Terminal 1 (continued)
>>> gtk.gdk.screen_width()
1280
>>>

Expected:
Terminal 1:
python
>>> import gtk
>>> gtk.gdk.screen_width()
1280
>>>
Terminal 2:
xrandr -s 800x600
Terminal 1 (continued)
>>> gtk.gdk.screen_width()
800
>>>

This works in F-10 beta but not in rawhide, I suspect the following gtk chsange from 2.14.1 -> 2.14.2:
* Don't use XRRGetScreenResources, since it doesn't work well


Version-Release number of selected component (if applicable):
gtk2-2.14.3-2.fc10

Note that pygtk2 didn't change between F10-beta and rawhide and thus is not suspect.
Comment 1 Jesse Keating 2008-10-07 12:57:13 EDT
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 :/
Comment 2 Søren Sandmann Pedersen 2008-10-21 00:13:01 EDT
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.
Comment 3 Hans de Goede 2008-10-21 04:03:20 EDT
(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).
Comment 4 Søren Sandmann Pedersen 2008-10-21 10:53:23 EDT
Assigning back to Matthias who can make decisions about pumping the event loop out of gdk_screen_width().
Comment 5 Matthias Clasen 2008-10-21 14:27:41 EDT
I don't see any justification for 'pumping the event loop' inside gdk_screen_width().
Comment 6 Hans de Goede 2008-10-21 14:36:57 EDT
(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.
Comment 7 Matthias Clasen 2008-10-21 14:45:33 EDT
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.
Comment 8 Matthias Clasen 2008-10-21 14:51:09 EDT
> 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.
Comment 9 Matthias Clasen 2008-10-21 15:51:01 EDT
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
Comment 10 Adam Jackson 2008-10-21 16:55:48 EDT
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.
Comment 11 Matthias Clasen 2008-10-21 23:57:04 EDT
Unfortunately, I sill see the extra crtc change notifies with width/height == 0/0
Comment 12 Matthias Clasen 2008-10-22 00:13:45 EDT
I also see 2 XRRScreenChangeNotify events, btw, one with the old size and one with the new.
Comment 13 Matthias Clasen 2008-10-22 19:24:20 EDT
The background resizing problem was fixed in eel2-2.24.1-3.fc10
Comment 14 Bug Zapper 2008-11-25 22:31:28 EST
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
Comment 15 Bug Zapper 2009-11-18 03:30:39 EST
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
Comment 16 Bug Zapper 2009-12-18 01:29:51 EST
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.

Note You need to log in before you can comment on or make changes to this bug.