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

List:       xfree-render
Subject:    Re: [Render] XRANDR implementation experience and questions
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-24 13:46:09
[Download RAW message or body]

On Thu, 24 Jan 2002, Keith Packard wrote:
>Around 19 o'clock on Jan 24, Hamish Rodda wrote:
>> Xft fonts are rendered too small and with size decreasing proportional to
>> decreasing screen resolution - would this be caused by incorrect
>> dpi/screen size values reported by X?
>
>Are you smashing DisplayHeight and DisplayHeightMM in the X display
>structure?  Xlib doesn't do that on it's own as we're not sure it's a good
>idea for all applications (yet).  Just do:
>
>	DisplayHeight(dpy,screen) = (new display height)
>
>and things may work a bit better.

I think this may be a problem in Qt, then... all I've done is convert the 
xrandr program to a GUI.  Note that this only affects newly started 
applications. Perhaps I should file a bug with Trolltech?

>> The question was asked as to whether it is possible to detect whether
>> hardware has been rotated, as in a rotateable LCD panel. I don't know if
>> the hardware does at the moment or not, but it might be interesing to
>> consider adding a "RRHardwareChangeNotify" event to the protocol so window
>> managers can detect it when it happens (of course, this would require X to
>> detect the change and pass it on).
>
>That's a good idea.  It can send the size and orientation in the event.

Sounds good.

>> The other question was about Xinerama and multihead, and interactions with
>> them. Will there be any issues here once support is in the core server -
>> eg. will the screens be able to be independantly resized and rotated?
>
>Yes, there are issues as RandR doesn't have a separation between the root
>window and the screen number.  It may be relatively easy to add the screen
>number in the relevant places and have things "just work".

Sounds good too.

>> Do you have an eta for the extension's implementation into the core
>> XFree86 server, even a general one?
>
>I have the feeling that adding resize will be the easiest to do given the
>current server architecture; rotation and depth switching seem
>significantly harder at this point.  We may take the shorter path for now
>and work on the restructuring necessary to handle the remaining parts in a
>later release.  If we do that, it could be ready for XFree86 4.3 which
>will be released sometime this summerish.

I would hazard a guess that the majority of users are more interested in 
resize than the other functions, so that sounds like a good plan. There is 
less work to get KDE ready for that, too.

Thanks for your help.

Hamish
_______________________________________________
Render mailing list
Render@XFree86.Org
http://XFree86.Org/mailman/listinfo/render
[prev in list] [next in list] [prev in thread] [next in thread]