Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Development page
| |||||||||||||
Linux Graphics News (Linux Journal)
The Linux Journal has an overview
of development in the graphics area. "By providing a complete
direct rendering solution for OpenGL, the DRI3 and Present extension
provide applications with the key benefits promised by Wayland, without the
need of replacing X. Initial implementation of these extensions has been
done, but they've not yet landed in the Xserver repository. If it lands
soon, we may see this functionality in Xserver 1.15, scheduled for release
in September or October; otherwise it'll need to wait for 1.16 this
spring."
(Log in to post comments)
Linux Graphics News (Linux Journal) Posted Aug 14, 2013 22:41 UTC (Wed) by ovitters (subscriber, #27950) [Link] I don't understand the following: A common misconception about the Wayland project is that it is intent on literally replacing X. A more accurate view is that it is a technology incubator for proving out design concepts. Obviously Wayland is not intended to replace everything within X. But this quote seems to suggest that it is just something for developers to play with, but then everything will be implemented in X. That seems utterly wrong, so I guess my interpretation of above is wrong. Don't get what is meant with above.
Linux Graphics News (Linux Journal) Posted Aug 14, 2013 23:54 UTC (Wed) by HelloWorld (subscriber, #56129) [Link]
I interpreted it the same way. I think the article is simply wrong about that.
Linux Graphics News (Linux Journal) Posted Aug 15, 2013 7:06 UTC (Thu) by Felix (subscriber, #36445) [Link]
Yeah, I found that sentence also strange but I guess it's this old technique where you use the broadest extend of a statement and then tell people that's untrue (instead of just using a more moderate interpretation of that statement).
The only thing that might support the article's statement is that even Wayland developers assume that X clients will be supported for a very long time so not all parts of X will be removed.
Linux Graphics News (Linux Journal) Posted Aug 15, 2013 23:50 UTC (Thu) by mmarq (guest, #2332) [Link]
And what about drivers ?.. would they be removed to ?
The juicy stuff is still going DRI(3), mesa/gallium3D and centered around X
Would AMD and Nvidia comply with what took by now years to support properly, and start branching all their efforts to support the new display systems ?
I can anticipate some answers on costs of transitions, a big "F 'em , give me all the info i'll do it myself" lol... Sometimes is this "disconnection" with reality i can't understand on OSS projects.
Couldn't there be a way to have something new, without breaking compatibility, real improve/add/change the old, instead of a constant my way or the high-way.. this is the single most serious threat to evolution and adoption of Linux desktop, i see fragmentation and irrelevancy on the horizont, no matter how much better a new mechanism can be, usability has a strong trend of going down.
Just a example, the most single mass adoption of client side desktop is multi-seat LTSP, used in many many schools all over the world... those got the kiss of dead!...
Linux Graphics News (Linux Journal) Posted Aug 16, 2013 7:08 UTC (Fri) by Felix (subscriber, #36445) [Link]
Not sure if I'm feeding a troll here but I'll try one more post.
> And what about drivers ?.. would they be removed to ?
While you're right that a lot of effort goes into drivers (with a long way to go especially for the Open Source AMD/Nvidia ones) it's not true that the juicy stuff is centered around X.
Actually a huge amount of effort of the "wayland" work was to extract common stuff and put it into separate components/move it to more sensible places. That's why Wayland and Mir are actually doable. Mesa is a generic part and will be used with Wayland as well. It should be relatively simple to make an X-driver working with Wayland.
Also I'm under the impression that all new X extensions are really something like "let's ignore the old X cruft and get direct access to the hardware". With Wayland there is less cruft to ignore.
> Couldn't there be a way to have something new, without breaking compatibility, real improve/add/change the old, instead of a constant my way or the high-way
Maybe you really don't know so much about software development? Obviously everyone likes stable+new features but I really think you underestimate the cost of backwards-compatibility/API+ABI stability. X has been tweaked/extended a lot of times but it's clear that there needs to be a clear cut (after something like 30 years or so with the same basic protocol!).
Times have changed since the late 80s, previous assumptions about network/disk/cpu speed and latencies and required features are invalid nowadays and that has to be refleccted in the display architecture (=> protocol).
fs
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 5:53 UTC (Sat) by mmarq (guest, #2332) [Link]
I don't agree at all with this few
Actually i used Xfree86, and what i tested with KDE4.11 and XCB as "NOTHING" i mean "NOTHING" to do with that painful legacy that everybody states X suffers.
X as evolved quite a bit to. IF the rants are about the old X network protocol, it has stood the test of time, matter of fact in this regard "network" and "remote displays" neither Wayland or Mir comes even close, matter of fact they have none AFAIK RFOLMAO !
The so called katamari is more modular now than i ever thought possible, why can't X be the *OpenWF Display* for Wayland and Mir, "the server" while almost integral as they are Wayland and or Mir "proxy" servers following the guidelines of NX, and be the *OpenWF Composition* (window manager)... meaning x wont be responsible for any composition or responsible for window management.
Yes it means change more X instead of replace, at least Xpar is going in which is already in the footsteps of NX... and **millions of kids in schools all around the world would be very happy not having to be stuck with replaceable tech, but nothing to replace it with equal superb functionality.**
Isn't the last ** ** ironic ? ... or insane in the battles for dominance and adoption ?
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 17:39 UTC (Sat) by magcius (subscriber, #85280) [Link]
I just looked at OpenWF. What a useless standard. Output is possibly the easiest thing about windowing systems today, but Wayland is already miles ahead of what X was.
The complicated things in building a new windowing system is input management (a whole other can of worms) and coordination between windows: drag and drop, clipboard, how to give specific properties about what your window is (what's its title? Icon? Is it a dialog? What app does it correspond to?)
Can a multiwindow process like GIMP say "my toolbox window should be raised above the image canvas window whenever the user clicks on it" in OpenWF? Does it prevent menus from going off the edge of the screen? Does it have good semantics for how cursors are defined? The image formats and where their hotspots are? Input methods so Chinese users can type complex characters?
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 18:04 UTC (Sat) by Felix (subscriber, #36445) [Link]
> I just looked at OpenWF. What a useless standard. Output is possibly the easiest thing about windowing systems today, but Wayland is already miles ahead of what X was.
I guess it's for good reason that they state on their website:
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 18:01 UTC (Sat) by Felix (subscriber, #36445) [Link]
> X as evolved quite a bit to. IF the rants are about the old X network protocol, it has stood the test of time, matter of fact in this regard "network" and "remote displays" neither Wayland or Mir comes even close, matter of fact they have none AFAIK RFOLMAO !
Ok, you're officially a troll now: Wayland has remoting support and that topic has been discussed so often that you can get real facts by just using a search engine.
> millions of kids in schools all around the world would be very happy not having to be stuck with replaceable tech, but nothing to replace it with equal superb functionality.
Why are you assuming that functionality goes away with Wayland (not sure about mir) compared to X? If we can trust the wayland developers at all working with (non-trivial, "modern" as in GTK3/QT5) remote apps will work better than currently with X.org.
That's it from my side. I'll stop feeding trolls now.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 20:02 UTC (Sat) by mmarq (guest, #2332) [Link]
> Why are you assuming that functionality goes away with Wayland (not sure about mir) compared to X? If we can trust the wayland developers at all working with (non-trivial, "modern" as in GTK3/QT5) remote apps will work better than currently with X.org.
VNC ? give a break!
why don't they use X ?.. its better... Xpra is actually ~1000 lines of code, and already can do things better than VNC.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 21:10 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
xpra uses a VNC-like protocol.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 23:20 UTC (Sat) by Jonno (subscriber, #49613) [Link]
> why don't they use X ?.. its better... Xpra is actually ~1000 lines of code, and already can do things better than VNC.
Because Weston (the Wayland reference implementation) can already do better than Xpra, using only 1090 lines of C, compared to Xpra at 939 lines of C plus 21927 lines of Python.
Xpra is a composing window manager that cheats and doesn't compose the windows, but just copies the window buffers from the X-server, compresses them, and send them over the network instead.
Weston is a composing window manager that, when asked to, cheats and doesn't compose the windows, but just compresses the window buffers and sends them over the network instead.
The main differences are that Weston does one less local copy of the image data, and that Weston are told by the application when it is *done* rendering a frame and uses that, while Xpra just tells the application how often will scrape the buffers and hope the application is smart and fast enough to not be in the middle of drawing at the time (which most applications thankfully are).
Oh, and Weston makes it possible for the application to use HW-accelerated OpenGL when rendering its windows, while Xpra limits all applications to SW-rendering.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 8:30 UTC (Sun) by chris.wilson (subscriber, #42619) [Link]
Wrong. Xpra neither imposes an extra copy nor limits the other clients to software rendering. As far as rendering goes , Wayland is merely a subset of X. Wayland imposes policy on the system, X does not. It remains to be seen whether that policy is good for tomorrow's hardware. It is not the right approach for yesterday's and given the strong pressure towards power efficiency future hardware designs already look not to favour the Wayland forced compositing model.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 10:03 UTC (Sun) by Jonno (subscriber, #49613) [Link]
> Xpra neither imposes an extra copy nor limits the *other* clients to software rendering
I'm talking about the clients *of* the Xpra X-server. You can not use HW accelerated OpenGL to render an application and then ship the window over the network using Xpra. Of course you can still use OpenGL on local clients running simultaneously with Xpra, that is not the issue.
> As far as rendering goes , Wayland is merely a subset of X.
An X driver can only use window buffers it itself manages, which is why you can't run one application on an NVidia discrete GPU and a second application on an AMD discrete GPU and then have them composed and displayed on a Intel IGP, nor run an application on any GPU and then "compose" it on the CPU-based "dummy" driver Xpra uses.
With Wayland this is not a problem. Each application uses whatever window buffers it wants, and as long as there is a kernel driver that can handle them Weston can compose them onto whatever buffer it wants.
Linux Graphics News (Linux Journal) Posted Aug 19, 2013 10:10 UTC (Mon) by mmarq (guest, #2332) [Link]
> Not quite. While Wayland does not allow any kind of rendering you can't get to work on X, it is more flexible in how you can mix-and-match them.
> An X driver can only use window buffers it itself manages, which is why you can't run one application on an NVidia discrete GPU and a second application on an AMD discrete GPU and then have them composed and displayed on a Intel IGP, nor run an application on any GPU and then "compose" it on the CPU-based "dummy" driver Xpra uses.
Thats is exactly what is a non non non-issue. And why Mir.
With HSA on one side, and intel on another... and Nvidia on the middle... the trend is exactly about "divergence" not mixing GPUs. Its all up to drivers and what those can do, but the LucidLogix bridges that SNB used is a thing of the past, doubt AMD and even Nvidia will be twisted to comply.
Ubuntu is HSA, so Mir i think will follow closely that standard (along with Khronos). Nvidia if Tegra, which is ARM, is going forward will be compelled to join HSA, that leaves Intel isolated. But not they care, they will invent something similar to the other standard superior points, matter of fact i think making PCIe cache coherent is being accelerated.
Wayland approach is "commercial intended", which already cost them criticism about this client(display all the advertising you want) vs server side composition.
Linux Graphics News (Linux Journal) Posted Aug 19, 2013 9:47 UTC (Mon) by mmarq (guest, #2332) [Link]
> Oh, and Weston makes it possible for the application to use HW-accelerated OpenGL when rendering its windows, while Xpra limits all applications to SW-rendering.
ummm... no, AFAI could read, the Xvfb scheme that Xpra uses now in the "remote" applications is going to be deprecated. Matter of fact its being developed for Xv using OpenGL, that is as example, video acceleration by the GPU SIMD arrays, instead of using the Video decoder engines (UVD, Purevideo etc).
So i think criticism is once more late lol...
Besides one very strong point in favor of Xpra is "persistence", a single window state is preserved even if the network connection is interrupted.
If Weston can do that also ( don't know) and then uses a rootless X server for compatibility (with all apps, there isn't one wayland yet)... why re-invent the wheel (X will be needed in any case) ?
why couldn't the network part of Wayland be X (handhelds don't need network, so in here doesn't apply) ? ( i suspect why, but it aint technical reasons and it aint pretty lol)
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 6:11 UTC (Sat) by mmarq (guest, #2332) [Link]
> Times have changed since the late 80s, previous assumptions about network/disk/cpu speed and latencies and required features are invalid nowadays and that has to be refleccted in the display architecture (=> protocol).
But that "line of thought" lets replace Linux kernel to LOL... AFAIK its almost 20 years now, never used the series 1 kernels, but started using series 2.. yes long time ago..
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 17:55 UTC (Sat) by Felix (subscriber, #36445) [Link]
>> Times have changed since the late 80s, previous assumptions about network/disk/cpu speed and latencies and required features are invalid nowadays and that has to be refleccted in the display architecture (=> protocol).
> But that "line of thought" lets replace Linux kernel to LOL... AFAIK its almost 20 years now, never used the series 1 kernels, but started using series 2.. yes long time ago..
Actually your statement is not a fair argument because you try hard to misinterpret my statement.
It's not about replacing a project just because it is old. 'gcc' and the whole set of gnu utilities are around for a long time and they are still working nicely.
But let's use the kernel as example: If you compare Linux 2.0 (or 2.2, 2.4) with any recent version you'll see that the code saw *major* architectural changes. Just from the top of my head the whole hotplugging (including CPU hotplug), internal modularity, scaling to a huge number of CPUs, SELinux, real-time improvements, dynamic ticks, ...
X would need a similar changes - it's been characterized as a almost complete operating system in itself with particularly bad IPC mechanism at its core. But as long as you want to keep compatibility with the X protocol (as in X11) you are left with a lot of old cruft. Just check the conference sessions by X+wayland developers for details.
My favorite example is that the X protocol does not allow you to lock the screen while a menu is open. The WTF-rate in X is really high.
Changing that means necessarily breaking backwards compatibility and IIRC the feeling of the wayland developer(s) was that starting a completely different project would be easier - otherwise there might have been too many people insisting upon more backwards compatibility and edge case features, bloating the new protocol again.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 19:36 UTC (Sat) by mmarq (guest, #2332) [Link]
> Actually your statement is not a fair argument because you try hard to misinterpret my statement.
no!.. cold rationally the troll is you... besides insult and "hope" it will be better, which can be said about any project even different version of the same project, with a high percentage of success, you presented no other pertinent argument but replace it because this is not the 80's. LOL
and for clarification, OpenWF (display composition) is about mobile, but like OpenGL ES it eventually merge. Besides OpenWF is a standard in heavy phase of arguing, not a "in stone" kronos standard.
> My favorite example is that the X protocol does not allow you to lock the screen while a menu is open. The WTF-rate in X is really high.
For crying out loud that is no argument... and WTF-rate is measured by what, what is the "scientific" metric... sounds more like a "propaganda" slogan and i just happen to hate filthy snake oil salesmen... its enough the world has to put up with politicians... please don't go that way.
> Changing that means necessarily breaking backwards compatibility and IIRC the feeling of the wayland developer(s) was that starting a completely different project would be easier - otherwise there might have been too many people insisting upon more backwards compatibility and edge case features, bloating the new protocol again.
I'm not against Wayland, i'm against the "politics" transpiring from it. Wayland started "a fresh", its very clear to me, because they wanted to address more closely the issues of the "mobile" and SOC display systems... X *network* is NOT needed... Of the three X, Mir and Wayland, Wayland is the one that follows more closely the mobile standards of Kronos, most notably OpenWF.
And so the politics that it must break backward compatibility seems to me just that, politics. Every day there are news of projects extended modified, yet an effort is maintained to keep compatibility... of course one less thing to worry, and could be "hairy", would certainly be *less expensive* for the financing backers of the Wayland project... and that is it ...
After all X did already broke the old model in a way with XCB. I think is quite possible X evolve and Wayland evolve to cooperate in a OpenWF (display/composition) model as guidelines, not necessarily follow integral the draft, yet maintain compatibility with past X apps without artificial hacks. But of course politely for the backers of Wayland the answer could be "why don't you mmarq finance it ?" ... that would be pertinent, i could accept that argument... OTOH insult for those that don't agree is no argument. (and Wayland "politics" for this environment is much to blame for)
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 15:42 UTC (Sat) by Arker (guest, #14205) [Link]
"X has been tweaked/extended a lot of times but it's clear that there needs to be a clear cut (after something like 30 years or so with the same basic protocol!).
Times have changed since the late 80s, previous assumptions about network/disk/cpu speed and latencies and required features are invalid nowadays and that has to be refleccted in the display architecture (=> protocol)."
Do you have anything *specific* in mind? Or is this merely a blind assumption that anything old must be out of date?
The hardware characteristics you mention have probably changed less than you are thinking. You have to keep in mind X wasnt designed to run on the PCs of 80s vintage connecting with a modem - these were high power workstations sitting on ethernet LANs. And X is quite agnostic, it runs happily on top of a very wide variety of hardware and software.
So what, specifically, is so fundamentally wrong with it again?
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 17:35 UTC (Sat) by magcius (subscriber, #85280) [Link]
Right now, an X server still supports bitmap fonts and state-of-the-80s nonantialiased graphics. The rest of the world has moved on, and we've introduced antialiased graphics through software rendering and the RENDER extension. Removing this means slimming down the size of the display server. Less code to load into memory. Wayland doesn't have any drawing protocol at all.
Right now, an X server still supports the Expose model of drawing. Window contents are forgotten about, and clients need to redraw them. Ever since video memory has gotten cheap and abundant, we can allocate video memory to each window instead of playing framebuffer tricks. And we can also do alpha blending since we have the pixels to blend against. Wayland makes each client attach a "buffer" which the compositor will render.
Right now, an X server still supports global grabs, making it hard to have secure and reliable systems. I can make an app that requires you to reboot your computer, as it seems that the system has effectively frozen. Wayland does not have any grabs; it models the app's intent for why it wants to use grabs, and gives the compositor complete control about who it wants to obey. This also means that the screensaver can show up if you have a menu open in your application.
Right now, an X server still handles all stacking and focus management behavior, and does it in weird and quirky ways. A window manager has to implement hundreds of lines of stack prediction code to know which window will be on top or on the bottom without making a round trip to the server. Did you know that keyboard focus is influenced by where the mouse pointer is on the screen? Again, Wayland gives the compositor complete control over what we have to do here.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 19:31 UTC (Sat) by lsl (subscriber, #86508) [Link]
> Did you know that keyboard focus is influenced by where the mouse pointer
> is on the screen?
I surely hope so. In any sane system the keyboard focus is *exactly* where the mouse pointer is positioned on the screen.
SCNR.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 21:09 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Hey!
That's your personal preference. Wayland can emulate focus-follows-mouse just fine.
Personally, I hate it.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 2:08 UTC (Sun) by magcius (subscriber, #85280) [Link]
I'm not talking about focus-follows-mouse, actually, though I see how you'd get confused.
Normally, key events are delivered to the explicitly set input focus window, but if the mouse pointer is in a child of the input focus window, then it's sent to there instead.
I can't figure why this is good behavior rely on this; an app should simply use Enter/Leave events to set the input focus to the child they want.
It breaks if you want to use XEmbed or similar to embed one window inside another (used for tray icons or embedding your emacs window inside your app, which some people like to do) -- if your app window has key focus, and the mouse is inside the tray icon or emacs, then the app doesn't receive keyboard shortcuts.
What GTK+ does to solve this is put up a large InputOnly window as a child of its own X window, and ensures it's above everything else.
Linux Graphics News (Linux Journal) Posted Aug 17, 2013 20:12 UTC (Sat) by mmarq (guest, #2332) [Link]
Glamor, XCB, D-BUS, Xpar, DRI3000 (DRI 3 )
I think you are talking mostly of the past
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 2:03 UTC (Sun) by magcius (subscriber, #85280) [Link]
No, all those features I mentioned are still part of X and can't be worked around without breaking protocol.
I was only talking about the protocol, not implementations of it (which Glamor, XCB, DRI3 are about). Of course, all these new developments are nice, but all of these cannot be fixed without designing a modern X protocol that's allowed to break compatibility. What do you think Wayland is?
I don't see how DBus is relevant to anything I'm talking about (we're not replacing it, and it's still in use Wayland, of course)
I don't know what Xpar is, and Google apparently doesn't either.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 6:20 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> No, all those features I mentioned are still part of X and can't be worked around without breaking protocol.
well, you don't have to use those features if you don't want to. the X protocol doesn't require you to translate new functions into these old functions.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 12:31 UTC (Sun) by magcius (subscriber, #85280) [Link]
Tell me how to solve those last two issues I posted above without designing a new protocol.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 16:25 UTC (Sun) by mmarq (guest, #2332) [Link]
ummm...can't protocols be extended ?
As example why X12 ? ... a rolling release as Linux project is much better approach, as long a truly compatibility effort is made, meaning large part of what is "extensions" could be part of the "protocol" no ? ... its not like kernel ABI but i can trace parallels, specially on development, and then ppl shouldn't worry too much about deprecated/obsolete items, only when they break, and yet fix or discard, it shouldn't be too much of a worry..
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 19:39 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
Well, if it's just a matter of wanting to disable or limit the global screen grab, make an X server that lies to the app when it requests this and don't grant it.
As for window stacking order, I don't see why the server telling you what the order is would be a problem, remember that the X server is sitting there with the user and may be displaying windows that are being generated on many different systems that don't know anything about each other. Where else would you determine the stacking order of the windows?
By the way, I don't buy the argument that video ram is now unlimited (or effectively so) and so there's no need to have apps be able to handle the expose.
Assuming that no app makes a window larger than the screen (which is not going to be the case), and there is no non-window data in your video ram, 1G of video ram will hold about 128 windows on a HD display (~2M pixels, 32 bits/pixel)
that's not a very high limit, and there are a lot of other things your video ram is used for..
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 10:07 UTC (Sun) by mmarq (guest, #2332) [Link]
> I don't see how DBus is relevant to anything I'm talking about (we're not replacing it, and it's still in use Wayland, of course)
IF the idea is exactly about "direct rendering", kind of X doesn't do any "composition", then D-bus can be very relevant, an unless they changed it, last i checked D-bus isn't in Wayland (and will be in Linux kernel).
I like Wayland for this, seems a simple, robust, feature rich for the purpose intended, display systems for SoCs, it could be nice for handhelds.
But it certainly is not yet nice for workstation, professional (if ever will be, it will take a long time)... it lacks multi monitor, proper multi seat, hot input plug, multi GPU, and network remote monitor, remote applications not only remote desktop like with VNC... and like X it could use "pervasive multi-threading" that only Mir seems to embrace now.
I think X is going to rock in all that, and its not only XCB, D-BUS and DRI3...
XCB seems to address many of the drawbacks
X Synchronization Extension Protocol
FD passing for DRI.Next
Completing the DRI3 Extension
The Present Extension ( multi-monitor, the old Xinerama is history, obsolete)
Multiple cursors ; X Hotplug Proposal, **XInput Hotplug**
Animated cursors, CursorHandling, PointerAcceleration
XKeyboardConfig (perhaps we can start using all multimedia keys)
**Multi-touch events are now supported for touchpads and touchscreens** which can report position information on more than one finger providing input at the same time, such as found on many tablets and recent laptops.
http://www.x.org/releases/X11R7.7/doc/xorg-docs/ReleaseNo...
Multiseat (for professional, next crop AMD, Nvidia will support GPU virtualization)
Panorama wallpapers(it will be nice if "dreamscene" aware)
VideoAcceleration,VDPAU, VD, XvMC (can Wayland or Mir use full feature of this drivers ? )
http://nouveau.freedesktop.org/wiki/VideoAcceleration/
Better driver support than Wayland Mir ( this if those can use some of what is there, if not!...) for Intel AMD and Nvidia and *VMware*.
Xwin/Cygwin, Xquartz, to run on Windows and Mac platforms, and IMO, either Gnome or KDE should be about "desktop" and run on as many platforms as possible
http://www.x.org/wiki/Development/Documentation/XserverSo...
More, including the on the "limbo" X12
Most of the "rightful" anti-X rants seems more than a decade old
> I don't know what Xpar is, and Google apparently doesn't either.
A kind of faq might help
------------------------------------------------------------
Replace most of that (considering some *NOT ALL*, could be reused) with what ?
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 10:44 UTC (Sun) by mmarq (guest, #2332) [Link]
And MESA seems clearly a counter part of DRI, which is clearly more based on X, and are based on MESA/DRI drivers some of the more juicy stuff, which in their turn is a counter part for in kernel drivers mostly via DRM... hUMA seems to be on Radeon centered drivers (don't know if ARM/MALI-Imagination could used it since will be a HSA kind of "standard"(hUMA))
http://dri.freedesktop.org/wiki/R600ToDo/
.. nothing of that is yet based on Wayland (if wayland can use all of the same, if not a lot of development effort is ahead )
http://www.mesa3d.org/relnotes/9.1.6.html
An with those drivers, as example not only the many "other languages bindings", the MESA/DRI also offers support now for OpenCL via the "clover" extension.
Why couldn't be Wayland+X or Mir+X (or waylandX or Xwayland (whatever), the same for Mir), if handheld use only Wayland/Weston kind of setup, if "professional" use the more elaborated scheme (the same for Mir) ????
At least like Wayland and somehow Mir, X is already detaching completely Display from Composition/windowing with the new MESA/DRI, XCB centered scheme... like the OpenWF foresees... seems like Wayland Mir are only addressing the old X, like if counting this one couldn't evolve...
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 12:36 UTC (Sun) by magcius (subscriber, #85280) [Link]
I know about all of that. I talked to Keith Packard at GUADEC about DRI3, and I've contributed to the design of it. I've written X clients in pure XCB. It's not a forward-facing solution.
"it lacks multi monitor, proper multi seat, hot input plug, multi GPU, and network remote monitor, remote applications not only remote desktop like with VNC"
Wayland is simply a protocol, and it doesn't prohibit any of this. Implementations may or may not support it. Weston supports all of that (yes, even remote applications), and the GNOME Shell port we're working on does too.
Linux Graphics News (Linux Journal) Posted Aug 18, 2013 17:11 UTC (Sun) by mmarq (guest, #2332) [Link]
Tell me something, couldn't Wayland and X as protocols merge somehow (in the guidelines of display + composition/window of OpenWF), on a rolling release model ? ... that is, without "fixed" servers and then inventing outside extensions, most abhorrent IMHO servers on top of servers only for compatibility sake, that is, use only the parts of the protocol you wish, but all the possibilities are present, and in that logic obsolete mechanisms shouldn't worry, neither be cause for wars.
Does a server have to use all of a protocol ?
A rolling release shouldn't scare either, then "a possible wayland server" could use all or the pertinent parts of Mesa/DRI and their drivers, instead of re-inventing the wheel once again, matter of fact it could be X also, perhaps a better X, instead of forcing a world wide community to program handheld apps, suitable to sell in app store like reps with few modifications, showing the finger to all the enormous legacy baggage in the process.
True, X apps perhaps are not the best approach for handhelds, but that is up to the app developers, they could use only pertinent part of the Wayland + X protocol present in a possible Wayland display system, discard the transport and network parts if wish, but they wouldn't be stuck in any model, their apps would be much more expandable, nevertheless don't be surprised if they choose XCB, even without network, over the actual Weston model.
Then of course it would had to be the Wayland+X/Weston system or more specifically a "possible Wayland server", if tailored more particularly for SoCs, to comply with the apps choices and developments, not the other way around (yes it would be more expensive to develop and maintain, and a saint patient to deal with possible "choice" bickering, but commercial projects should sustain themselves).
Linux Graphics News (Linux Journal) Posted Aug 15, 2013 16:06 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Until Wayland is landed in Enterprise Linux, it is freetard's toy at the end of day.
Linux Graphics News (Linux Journal) Posted Aug 15, 2013 16:31 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Until you have something to say other than trolling, you're a tard at the end of day.
That should do it Posted Aug 15, 2013 16:35 UTC (Thu) by corbet (editor, #1) [Link] This doesn't seem like a thread that is going to lead to anything useful, perhaps we could all stop?To "maxiaojun": you really do seem to go out of your way to prod and poke at people. I'll ask you, please, for the last time, to stop. This kind of thing is not helpful to anybody.
That should do it Posted Aug 16, 2013 0:17 UTC (Fri) by mmarq (guest, #2332) [Link]
Yeah! not nice...
But i think its only the consequences of war... yes.. sometimes i got this feeling that the Linux "client" world landed itself in the middle of a GP/GPU display war and possible future models of programming and adoptions.
If ppl didn't know, Ubuntu is now a member of the HSA Foundation
While Wayland and X are if not directly, at least indirectly financed and influenced by Intel... how could this happen ?
To me is no surprise Mir, and the more aggressive parts on polite verbiage are yet to come, and will not come from occasional posters, but by the forces behind the trend pushing.
That should do it Posted Aug 17, 2013 11:31 UTC (Sat) by maxiaojun (subscriber, #91482) [Link]
Hello editor.
I have nothing to stop. I actually almost forgot about this thread. I cannot care less about UrATroll™ [1] owners like ovitters. They use their UrATroll™ band to show their inability to give a convincing, logical argument.
The only thing concern me is that UrATroll™ owners are ultimately harmful to real large scale spread FOSS, that's the motivation of my various comments. I need to point out a different view point of FOSS. If people have problems seeing different views, I'd wonder whether free software is a misnomer. Even if its strict definition of freedom is unrelated to developer/user relationship.
You definitely can join the UrATroll™ party if you want, though.
Linux Graphics News (Linux Journal) Posted Aug 15, 2013 4:00 UTC (Thu) by mmarq (guest, #2332) [Link]
I think the author is confused, Wayland like Mir, was/is indeed intended to replace X. Only the recent developments of X concerning multi-display, remote display, multi-seat, multi graphics engines, seems to leave the question in the air, how is that replacement going to be, when the juicy stuff concerning support and usability happens exactly on the side of what is supposed to be replaced lol
The idea of a rootless X server "on top" of the main one... like preliminary tests with Mir showing a 10% regression in performance... is not bad... is A DISASTER.
And i'm not against Mir, i'm not against anyone, matter of fact i think Wayland/Weston will be worst, one of the strong points of Mir is "pervasive multithreading" of which i couldn't read about Wayland/Weston. Mir addresses ones of the "quirks" of X that doesn't have to do with the protocol "per se" as i understand... it uses "multithreading" and avoids long events from blocking other parts of the windowing/composition.
http://smspillaz.wordpress.com/2013/07/27/experiencing-th...
The problem is that no app will be Mir aware anytime soon, would Gnome or KDE apps be Mir ? would Libre/Open Office be Mir ?.. Mozilla ?... etc ?... The same can be said about Wailand/Weston.
Why can't all this guys cooperate ? ( the author of that article seems to come with the presumption that they already do, hardly the case when the "statements" are about "replacement", and discussions are flamewars.)
Following the "logic"... even ARM iGPs have the GPU, a display controller, and a video encoding/decoding engine. To illustrate further, on chip floor plans circulating, on Intel chips the display controller is on the opposites sides of the chip to the GPU, that is responsible for the image composition...
Way can't X be the engine for Display, and Wayland for windowing/composition, and use the multithreading approach of Mir ?
Wayland + X gives Wayland, that had a design effort to follow OpenWF, what it lacks. The idea of VNC, is not bad but a complete disaster, and essential is not only about remote desktop and seamless network, but remote display even for a smarth/super phone... like displaying in a large monitor using the new remote display Wifi standard...
More OpenWF, is OpenWF Composition and OpenWF Display, Wayland could be good at the first, and nothing beats X and the other IMHO.
So even X agrees in being replaced.. strange lol... what lacks is take the modularity of the "katamari" to make the core X deal essentially with "display" ( those display engines in chips)... and not have drivers for S3, Voodoo, i970 etc (what a joke lol) associated, but drivers for Streaminput, HDMI, DVI, VGA etc
XCB loses the hardwiring to X i think, which is already a great start i think, pity Daniel Stone defected when he is needed now to take the modularity of the katamari to the level that is needed lol
OSS should be about "extreme cooperation"... corporations should struggle in this indefinitely, due to the inherent self interests... but what seems to happen is exactly the contrary...
|
|||||||||||||