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
Not according to Jim Gettys - this is TBD.
This is not true about KDE being the first to add support for this extension. GTK v2.1 has had support for this already.
-> Sometimes, you just gotta break free from the shackles of proprietary code.
Rotated - Because you have one of those groovy rotating monitors and you want to view a document in protrait rather than landscape.
Mirrored - The example given is the document is along the lines of mirroring the diaplay so that when it is projected it looks correct, maybe this is something to do with a back projector I don't know.
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.
You'll note if you read some of the correspondence around this that various members of the GNOME team (and presumably KDE) are adding a control-centre gadget to do exactly that.
When, oh God, when, will people RTFA,
...fuckin' kids these days...
or just the post, for christsakes.
The feature you're asking for is exactly
what this extention allows.
Don't become a regular here -- you will become retarded.
1) dialog
2) kcontrolmodule
3) notification
4) popup
Sadly, none of these have anything to do with X windows. You can install OroborOSX (great software) on OS X, which gives you an x client and server, but you still can't acces Mac apps from another X-box.
I love Mac OS X, and a native X windows on it is my fondest wish for the thing. But I don't see Apple doing that any time soon.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Well, with Quartz you get a lot more than a pretty gui. You get a very fast, path based graphics, with free anti-aliasing to boot. This is not there just for looks! It has real uses.
Sure, people complain how slow Quartz can be and I admit that it is very slow when resizing windows, but XFree86 is actually slower on hardware with similar speeds, Don't believe me? Run the newest KDE with all the effects on (like animations) and AA fonts on a 500MHz machine, then play with OS X on a 500MHz iMac, You'll find Quartz to not only be faster, but better looking to boot.
Don't diss Quartz, it can do awesome stuff (microsoft's GDI+ doesn't stack up to it either.)
Using Quartz, you can actually draw things at theSUB-pixel level, it does this by varying the intensity of what you draw and can be very useable in real world appliations. Imagine software for planning projects and suchusing timelines. With Quartz, you could zoom in and out of the timeline in real-time AND be able to actually READ and see the diagrams even at 10% of their normal size!
To sum it up, Quartz is good sh*t!.
Your WM will want to understand it, and your toolkit should understand it. But if you read the paper, you'll see they have solutions to help apps that are unfamiliar with the extension cope with their world changing underneath them.
I won't speak to raw performance issues here, but the network load of the X protocol can be greatly alleviated by dxpc or better yet MLview dxpc, which claims to be around the speed of Citrix ICA.
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
You obviously don't know what you're doing, have misconfigured, etc.
I have a set of boring-ass old PII/400 workstations with 128MB memory here running original GeForce256 cards using the NVidia driver. Everything in KDE -- window decorations, menus, anti-aliased text, scrolling content -- draws instantly, just as it does in Windows. There is none of the 'paint across the screen chunkily' problem you describe. Maybe it actually is the drivers. Did you ever think of that?
And on this same network, there are two headless Slackware 8 servers on which I often log in to KDE remotely. This is only a 10 megabit network and yet the KDE desktop works wonderfully; there are no real slowdowns whatsoever compared to the Citrix clients I've used elsewhere on the campus network.
Something is clearly broken on your setup.
STOP . AMERICA . NOW
right?
Wah!
For example, you should be able to tell an application running on your handheld computer to use a nearby desktop display, keyboard and mouse, or a projector on the wall. This should not require stopping and starting the application. You should be able to go home, and decide to import applications you left running at work. There are obviously security, authentication and authorization problems left to work out, but these are generally independent of the base window system.
Holly network is the computer, Batman! I gotta think about that one, but I'm sure it will not be comming to platforms that are still trying to extort per seat licensing and worry about more than one person running a word processor at one time. How's that for "ready" for the desktop"?
MMM, don't like frame buffer, it's been slow. The article talks about this frame buffer being faster than other frame buffers, but that does not make it as good as non frame fuffered servers, no?
Thinking over. Your turn.
Friends don't help friends install M$ junk.
Just to throw in a data point from a personal experience.
:)
I once ran mozilla from a dual PIII645 remotely from a NY hosting facility through my cable modem access in boston. It ran just as fast as my native mozilla on my k6II550. I thought it was interesting.
I believe some of the slowness you're seeing has to do with Gnome itself. I haven't used gnome2 yet but I hear it's snappier. and of course, there has been speed improvements in Xfree from v3 to v4 (from what I've noticed). I have not noticed the issue you have mentioned on my machine.
A lot of the X issues people mention (or don't name at all) are actually from the tookits and applications and desktops themselves. I mean look at the amout of memory needed to run the latest linux/unix desktops. I miss how fast windomaker used to get started
If anything X is a work in development as this latest extension shows. And we're stuck with it for the time being.
narbey
-- "The evil stops here" -Petr
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.
Try "startx" right away, without running xconfigurator, or xf86config. See what you get. Save it as XF86Config_working, then go ahead and run xf86config and try and get something better. If you get X to run, at least you won't overwrite a good configuration while you try and get one running;-) (This is my tip of the day, works on Grey Cat Linux.)
Rapidweather's Linux Screenshots.
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.
and now dynamic sizing/resizing in X.
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
Windows has never had -- and still doesn't -- rotation, which the XRandR also provides. Cool, now I can tilt my monitor on its side and view things in portrait mode.
The Mac supported this with certain display hardware (the Radius Pivot comes to mind), but most Mac hardware (of System 7 vintage, anyway) didn't support any resizing, dynamic or otherwise.
I can click the [Windows] start menu and it draws instantly. I can still see Gnome and KDE menus paint across the screen chunkily -- yes, this is on a P-4 machine with whizzy graphics cards, a gig of RAM, etc.
Then something is seriously fucked up with your Linux/X server configuration. I'm typing this on a P-III 550 with 512 MB RAM and a Matrox 200 graphics card, and "instant" is the word I'd use for the graphics. On a P-166 with 64MB and cheap S3 ViRGE graphics, it's a little slower to start drawing a menu, but once it does start the menu appears quickly, none of this "chunkily" stuff.
Makes you wonder why all those thin clients that boot Linux + X11 do it not to connect to an X server, but to run Citrix's ICA client for Linux to connect to a Windows 2000 server.
Umm, maybe because Windows 2000 server doesn't speak X Windows? (So, how do I set the DISPLAY variable in Win2K?)
-- Alastair
You need a card that can mix visuals, e.g., 24+8 overlays. My Matrox G450 can & XFree already supports the mixed visuals.
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.)
It's also possible that people may want to run XMAME and other such emulators on a monitor which has been rotated and placed inside a cabinet (or other display mount). While XMAME and other emulators may allow games to be rotated during emulation (usually one of the game's options), by allowing X to rotate the screen, it wouldn't depend on the emulated game to provide the rotation and it would provide consistancy among game orientations.
...and that's the way the cookie crumbles.
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
Can anyone give a reason why work hasn't been done in this area, preferably a technical one, I've heard many arguments of "X wasn't designed for that, that's not its purpose"
The argument that X Windows isn't supposed to provide this function is correct. The deficiency is that no universal alternate exists to fill the obvious gap. The reason is that the problem domain (limitless possible media types,) is beyond comprehension for the cooperative collective of developers involved. Instead, they cop-out and provide "text" only "clipboard" functionality in the base X protocol.
In theory, one would rely upon a GUI toolkit used to implement X Windows applications to handle clipboard media. However, there is no universal toolkit that provides this. Each toolkit solves the problem in it's own distinct manner. KDE, Gnome, Motif, etc., have all "solved" the basic problem to some degree.
Windows (and Macs, for that matter,) have the advantage of a proverbial King. Most of the time, freedom is better. However, in some cases having a King is very useful. The King can slam the proverbial fist on the table and arbitrarily chose a solution from among largely equivalent implementations. This creates a defacto standard, and we all get along with our lives.
Windows has one universal toolkit; the GDI. All other higher level toolkits respect the GDI. Thus, Windows has uniform and powerful clipboard behavior.
Here, in the *nix world, we have multiple equivalent solutions, backed by egos that know no bounds. No one has the power to force the others out, and the "customers" won't jump off the fence either.
Fonts suck in X Windows for the same reason. The problem domain of fonts is rife with ivory tower pedantry. The "ideal" font solution is probably computationally infeasible, and is therefore left to rot. The Microsoft world just pulled Truetype out of it's ass and got on with it. Of course, Truetype sucks badly, ask any font "expert."
Basically, X Windows is as far as you can go without some grownups in control.
Sendfile is an asynchronous file transfer service for the Internet, like
the sendfile facility in Bitnet: Any user A can send files to another user B
without B being active in any way.
Sendfile for UNIX, which is an implementation of the SAFT protocol (Simple
Asynchronous File Transfer) now offers you a true asynchronous file
transfer service for the Internet. Virtually any form of file can be sent,
including encrypted ones. The SAFT protocol will be submitted as an RFC in
the near future.
Under KDE, you can switch Kexboard layouts on the fly: ControlCenter->Connected Devices->Keyboard->Layout. Activate the layouts you want (dvorak is among them), and an icon appears in Kicker that lets you change the layout with a click (okay, two clicks).
xmove allows to do this.
Tt creates a "virtual" Xserver ; you run your apps in the virtual server, and then you can attach the virtual server to a real Xserver, and detach/reattach it to another real Xserver.
There are some limitations (real servers must have same bpp, for instance...).
<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
xmove could do some of what you want, moving clients between X servers. I haven't used it in 3 or 4 years, so I don't know if it still works.
From the man pages:
redhat 8.0 runs X at nice -10 out of the box.