[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Basic RandR support
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-11-23 21:45:32
Message-ID: 200611232245.33104.l.lunak () suse ! cz
[Download RAW message or body]

On Thursday 23 November 2006 17:24, Philip Falkner wrote:
> Attached are patches against r607190 that add support for XRandR.  These
> replace and add to my previous patches.
>
> 01_kdebase_randr-support and 01_kwin_randr_support add what's needed to let
> kwin build with or without RandR.

> These patches add automatic refresh rate detection.  This is my first
> attempt at working with CMake, so I've likely made a mess of it.

 No, sorry, tough luck. Maybe you'll manage to mess next time :).

> kwin_auto-refresh-rate is mostly unchanged from my previous attempt: if a
> refresh rate is specified in the configuration file, use it.  If not,
> autodetect with RandR if we have it, fallback to 50Hz otherwise.

 Well, I have some doubts about supporting 1kHz :) as monitors rarely go 
beyond 100Hz and this is not Quake to want to go beyond that, but ok.

> kwin_notify-screen-change sets kwin to listen for ConfigureNotify and
> RRScreenChangeNotify.  Basically, if we build without RandR, kwin will
> notice when the size of the root window changes, while if we build with
> RandR, kwin will notice size, refresh rate, rotations, etc.  In either
> case, it reacts by tearing down the composite scene, and building a new
> one.  This could be improved by comparing the old settings to the new and
> seeing what really needs to happen, but for the moment this brutish method
> lets compositing still work properly after screen changes, which it didn't
> before here with OpenGL or XRender.

 You were too fast to give me time to tell you Qt already takes care of this. 
There's Workspace::desktopResized() which gets called in such case, so just 
calling finish+setupCompositing() at the beginning of this function does the 
job as far as resizing goes. However since Qt checks if the size has changed 
this doesn't take care of refresh-only changes.

 Hmm. Most of the changes in this patch just duplicate Qt, so I'm not going to 
commit this patch as it is, but KWin will probably have to check for the 
event to detect refresh-changes. Maybe it shouldn't use the Qt signal at all 
then.

> Unfortunately, I can't test rotations, reflections, or multiple monitors.
> Would someone who could please let me know if these patches work for them?

 These should not matter. Rotations and reflections are done by X and XRandr 
gives only a way to configure them. Xinerama should not be affected by this.

On Wednesday 22 November 2006 03:40, Philip Falkner wrote:
> That would mean we'd need to recreate what we draw to on RR-change
> notification.  The simple (but expensive) way to do that would be to stop
> compositing, tear down the scene, make a new one, and start compositing
> again.  I wouldn't think RR-based changes would be that frequent, so maybe
> we could get away with this?

 Yes. One could try to just tell the scene to recreate the output buffer and 
perhaps what else matters to avoid resetting all effects and so on, but 
that's probably not worth it.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]