5 ms·
I'm confused. I've seen this a bunch of times, and I don't understand why Canonical submitted a patch to a video driver to "support" their Xmir window server. W
by lelandbatey 13y ago
I'm confused. I've seen this a bunch of times, and I don't understand why Canonical submitted a patch to a video driver to "support" their Xmir window server. Why does a video driver need to have code in it to support a window server? Isn't it supposed to be the other way around? Isn't the window server supposed to work on top of the video driver (and all the other hardware drivers)? What's going on?
- achat 13y agoWhile developing some application, did you ever feel that your SDK is lacking some feature which would make your app development much easier? So think the video driver as library and the windowing system as an application using video driver library.
- lelandbatey 13y agoYep. However, if you're trying to replicate something that's already built on top of an existing piece of software using the existing API's, I'd assume you wouldn't have to patch the platform just to build on top of it. However, as tinco explained[0], it seems that there is no "standard graphics api" for linux, and the "link" between window servers and graphics drivers is hard coded. So you do in fact have to patch the video driver to provide support for a new window server (on Linux at least).
- tinco 13y agoOn Linux it is actually the window server that provides the interface between applications and the video driver. Linux does not have a standard graphics driver interface like Windows does, at the moment is sort of defined by X, and since Wayland and Mir aim to replace X, the interface will be replaced too. This means that every driver needs to interface with each of the window managers. I would agree that is a silly idea, but such is the world when applications need very low level access to hardware to attain real time performance. You just get a tangly mess.
- lelandbatey 13y agoOk, that makes more sense (or at least explains why). I'm puzzled that there hasn't ever been anything done to make this less of a tangly mess; it seems like it'd be a huge step towards making linux a better platform to iron something like this out. However, that's probably just wishful thinking, as I have no idea what it'd take technically or politically to make that happen.
- tinco 13y agoThere have actually been many tries, Wayland being the most recent of them and now Mir. But because the earlier ones relied too much on the old X code, they were not succesful, and Wayland has not yet secured support from the graphics cards manufacturers (except Intel). Mir is promised to change all that, but we will have to see.
- jmillikin 13y ago> On Linux it is actually the window server that provides > the interface between applications and the video driver. This hasn't been true for a long, long time. Modern Linux applications directly call into the graphics driver, either through OpenGL or an intermediate library such as Clutter. > This means that every driver needs to interface with > each of the window managers. This is also not true. Window managers are driver-independent, and you can easily write your own window manager without any knowledge of the underlying hardware. You might mean "display server" instead of "window manager", but there's only one display server used in Linux, and that is X11. X11 was designed in an era before standardized graphics or input APIs, so it doesn't use OpenGL. As a result, it needs its own set of drivers for nearly everything (keyboards, mice, graphics, overlays). That's why Linux graphics drivers need to have special X11 support. Wayland and Mir are an attempt to replace X11 with a much thinner layer, handling only the bare necessities of getting the driver and user application together so they can talk OpenGL together.
- tinco 13y agoYou are right, I meant 'display server' instead of both 'window server' and 'window managers'.
- ihsw 13y agoBeyond that, it may be because Mir is GPLv3 licensed and Wayland is MIT licensed. Just a hunch.
- tinco 13y agoOh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..
- ihsw 13y agoIndeed, also X.Org is X11 Licensed (MIT license variant). Wayland and Mir driver support is pretty much a mystery, and Canonical has been trying to engage hardware designers (Nvidia, Intel, AMD) for support. This recent spate between Canonical and Intel may be indicative that the process isn't going well. Ubuntu's next LTS release is 14.04 so it's 8 months away, and if there's any surefire way to piss Canonical off then Intel us definitely getting that job done. I'm not trying to defend Canonical but it's hard to ignore the reality of the situation. I wouldn't be surprised if BSD licensing is on the table front-and-center during negotiations, considering the legal barriers surrounding GPLv3. Also, it makes me wonder where this leaves Valve. I get the distinct impression that they've been getting cozy with Canonical and they might be getting nervous about the situation.
- tinco 13y agoHmm, I would say the oppposite. The recent spate between Canonical and Intel might indicate that Canonical's engagement with competitors NVidia and AMD are going well. Canonical doesn't really need to cooperate with Intel, because Intel already makes excellent open source drivers for their graphics cards. I think Valve is the reason that Canonical can work together with NVidia and AMD, and that they're probably not nervous about this at all.
- spacelizard 13y agoNot really. GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile. This is a good thing for users of those devices. I can't defend Canonical's support of proprietary drivers, especially on these devices that are known to be used for such pervasive spying, but at least a non-hardware-locked device allows for workarounds (i.e. deployment of your own free drivers).
- route66 13y agoIt's outlined here: http://www.x.org/wiki/guide/concepts/#xisclientserver http://www.x.org/wiki/guide/concepts/#xisclientserver . In a nutshell, X "serves" the application to the (in- and output) devices.
- voyou 13y agoYes, I don't understand this, either. Note that a) the Intel X driver does not, AFAICT, have any special code to support Wayland and b) the code Ubuntu want to add appears to be for XMir, which is an X server that runs on top of Mir, not for the Mir display server itself. An X server running on top of a different display server should not need specific support in the drivers of the X display server; that XMir apparently does makes me worried Mir is going to be an architectural clusterfuck.
- gue5t 13y agoIt actually does have code to support XWayland, the analogue to XMir: <http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=xwayland&qt=grep&q=xwayland> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log... This code is an optimization, not a strict requirement, as you're right that in theory XWayland or XMir could be supported in a hardware-agnostic manner. For XWayland this is the (formerly "wlshm") xf86-video-wayland X driver: <http://cgit.freedesktop.org/xorg/driver/xf86-video-wayland/> http://cgit.freedesktop.org/xorg/driver/xf86-video-wayland/>, but it is much slower than the hardware-specific options (which also exist for the radeon and nouveau X drivers). I don't know if there's an equivalent hardware-agnostic X driver for Mir, but in no case would a production-quality windowing server have that as its only method of compatibility for an important hardware segment--both Wayland and Mir developers expect X-dependent applications to stick around for quite some time, so they must perform as well as possible. For what it's worth, my hat is firmly in the Wayland camp; its design is simpler, its development more open, and its motivations more clear than those of Mir. Canonical does a bad job of software stewardship and I'd hate to see them in control of the dominant graphics solution for Linux.