Slashdot Mirror
RandR Support on XFree86 4.3
Gentu writes "Great news from our favorite windowing system: [Hewlett-Packard] engineers committed a new extension to XFree86, called RandR. XFree86 4.3 (to be released in late 2002/early 2003), will have the ability to truly resize (not via the pseudo-resize CNTRL+[+/-] command), rotate, reflect and change the refresh rate of each screen of an X display on the fly. And KDE seems to be the first desktop environment to add support for the RandR extension."
Keith Packard provided GNOME patches a couple weeks ago.
ChangeLogs:
2002-10-04 Havoc Pennington
* src/display.c (event_callback): do XRRUpdateConfiguration()
if we have RandR extension, else poke in Xlib's screen struct to
update the screen size.
* configure.in: fix a bogus overwrite of cppflags,
add a check for RandR extension
2002-10-07 Mark McLoughlin
Support RandR extension by resizing the toplevel panels
if the screen size has changed. Based on patch from
Keith Packard - #94561. Requires gtk+ HEAD.
* basep-widget.[ch]: (basep_widget_screen_size_changed):
* foobar-widget.[ch]: (foobar_widget_screen_size_changed):
resize the toplevels when the screen size changed.
* multiscreen-stuff.c:
(multiscreen_screen_size_changed): re-initialise and request
a resize on the toplevels.
(multiscreen_support_init): connect to the "size_changed"
signal on all screens.
(multiscreen_reinit): re-initialise the monitor geometries.
Tried xmove?
Prescriptive grammar:linguistics
The RandR extension seems to.
It will then emulate, using the Render extensions compositing features, any visuals used by apps that are no longer accelerated. ( eg switch from 16 to 32, emulate 16 bit visuals.)
This means clients which don't know about RandR, and don't change visuals, will not break.
They (essentially) use Display PDF, an evolution of Display PostScript. There is no X server. What they gain from that is, well, a pretty GUI. One that does not have many of the useful features of X (no remote windowing, which matters when you're seling Xserves). More importantly, it has none of the X software, which means people have had to hack a working X server onto the platform - Apple refuse to - and run them there. If all you want are the pretty effects you can get from Display PDF, you can go contribute to one of the projects adding Display PostScript to X. There's not much that uses it, but you can have it.
Which means Apple may have a Unixish personality of their Mach core, but out of the box, no Unix GUI tools work.
And if you think Apple, who routinely sue people for producing OS X look-a-like themes would stand for you cloning the Quartz API, you can pass me some of whatever you've got.
1) dialog
2) kcontrolmodule
3) notification
4) popup
I then reclicked it, and there is no perceptable painting whatsoever. It's either there or it isn't. I can click over and over on it, and it pops back and forth (if I do it quick enough, I get a flicker effect and I think I can see where it is painting, but I'm not sure if it's just a optical effect of flipping back and forth).
KDE caches it's menu, and does a rebuild when you click it after n seconds of activity (the value is in a Properties panel somewhere, iirc). My guess is that the "repainting" is actually KDE rebuilding its menu after a period of inactivity.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Dude, you've got it all wrong. People often say that Quartz is almost like Display Postscript, but it's not at all. Display Postscript involved creating actual postscript code and sending it to a postscript intepretor for display on the screen. Quartz does not do that. However, it does share almost the same exact API as Display Postscript did, so I can understand the confusion.
Anyhow, Display Postscript was not intended to be an extension to X11, that came AFTER it was implemented on NeXT. Remember OpenStep on Sun and HP, thise systems only had Xwindows, so a XDPS system was needed for them only.
Another point, XRender works very similarly to how Quartz does. That is, clients draw in a pixmap and ask the Server to draw it (vs. asking the Server to just draw it). The WindowServer in OS X is kinda like a XRender only X11. Drawing commands are not sent to the WindowServer, only the client's pixmap of what their windows should contain is "sent" (shared really) to the Server. Hence, a lightwieght Window Manager.
Unfortunately not. From the spec as implemented.
RandR as implemented and integrated into the XFree86 server differs in
one substantial fashion from the design discussed in that paper: that
is, RandR 1.0 does not implement the depth switching described in that
document, and the support described for that in the protocol in that
document and in the XFree86 implementationhas been removed from the
protocol described here, as it has been overtaken by events.
These events include:
o Modern toolkits (in this case, GTK+ 2.x) have progressed to the point
of implementing migration between screens of arbitrary depths
o The continued advance of Moore's law has made limited amounts of VRAM
less of an issue, reducing the pressure to implement depth switching
on laptops or desktop systems
o The continued decline of legacy toolkits whose design would have
required depth switching to support migration
o The lack of depth switchin implementation experience in the
intervening time, due to events beyond our control
Additionally, the requirement to support depth switching might
complicate other re-engineering of the device independent part of the
X server that is currently being contemplated.
Rather than further delaying RandR's widespread deployment for a
feature long wanted by the community (resizing of screens,
particularly on laptops), or the deployment of a protocol design that
might be flawed due to lack of implementation experience, we decided
to remove depth switching from the protocol. It may be implementated
at a later time if resources and interests permit as a revision to the
protocol described here, which will remain a stable base for
applications. The protocol described here has been implemented in the
main XFree86 server, and more fully in the TinyX implementation in the
XFree86 distribution, which fully implements resizing, rotation and
reflection.
I just keep around an XF86Config file that's all set up for the XGA resolution,
Or you could add another layout section to your current file, and just call startx -- -layout blah. (Only tried on Debian with X4.)
You could do every single one of the things you mentioned with DGA in XFree86 4.0 already.
Of course, you can't run in a windowed mode, but if you're running a game, it's a fair bet that you aren't running windowed.
May we never see th
<eliza>Why do you think that it is going to get harder and harder to grow with X?</eliza>
(For that matter, why do you think X is bloated, or ugly, or slow, or obsolete, or inefficient?)
I suggest you check out the X extension mechanism. You know, the thing that makes possible such things as the RandR extension, which is what we're ostensibly talking about here. The original X11 design did not make any provisions for:
and much, much more. Yet these things all work fine today, without loss of any backward compatibility to older applications.
I agree with Jim Gettys on this one: people who say X is bloated and/or outdated are usually underinformed - meaning they have not really evaluated the alternatives or tried to design their own alternatives. Either that, or they are looking for something with a lot less functionality, like a simple framebuffer for a PDA.
(One thing I do think XF86 could still use is a widget set extension. I'm thinking individual toolkits like gtk2 or motif2.1, when installed on an X server, would register sub-extensions with it. The client-side libraries would use them if present, so most widget UI interaction would happen entirely on the server side. I think this would be very good for perceived UI latency. This is something I'd start investigating and hacking on if I had a lot more time than I do, but alas....)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README