Slashdot Mirror

These two files, window.c and image.c, are an entire simple GUI toolkit and an example program using that toolkit, for use with a Wayland compositor.

This directory is an entire compositing window manager that speaks the Wayland protocol. This is already impressively small, but keep in mind that most of the complexity here is in actually drawing to the screen and getting input events from hardware, something that Wayland has nothing to do with, and it's *still* small.

Wayland is simple because it is small, and it's small because it only concerns itself with communication between compositors and applications. There are already good APIs for drawing (cairo, opengl), so Wayland lets application developers use those, or whatever else crops up in the future.

No the problem with XDBE is that it was designed for on-screen clipped windows.

I don't see anything specific about clipping in the XDBE API, except that the back buffer is drawn with the same clipping as the front buffer. In the case of BackingStore (ancient) or XComposite (modern) there won't be any clipping.

Wayland lets the client tell the server to just "use" the new buffer, eliminating the unnecessary blt.

No, that's not how it works. If you're talking about the whole screen buffer, then sure. It works like that. The graphics card just twiddles the base pointer in the RAMDAC, or HDMI/DVI/DP encoder chip.

But for individual windows it does not work like that.

The individual window buffers still have to be drawn to the screen, however. For that, Wayland has to basically issue a bunch of glQuad calls or, a more modern equivalent. That's a trivial amount of effort for any card which supports OpenGL, but it still ultimately has to composite the individual window textures onto primary back buffer.

Your idea to eliminate the async window borders will not work. X does not have any method for the client to tell which window resize event it is responding do so the wm cannot tell if it is drawing the borders around the correct window contents.

Not sure I follow. The WM controls resizing of all the direct children of Root, by setting the Redirect flag. The application, or others can request a resize, but the WM has total control over the actual resizing.

fix that would work and fit with how X11 is to add an api so the wm just tells the client what size it wants the window to be but it is the client's job to resize the window, plus a "I am done drawing" message from client to wm.

ick. That would allow clients ot override the WM, so you could no longer use the window manager to force badly behaved programs to behave. Also, if the client is running slow, then the resize would hang until the client had finished.

Also there is a latency problem in that the wm has to wait for the "I am done drawing" message from the client before starting to draw the window borders.

The round trip ping time via IP is about 25us on my computer. Unix domain sockets are probably somewhat faster. You'll need about 700 round trips before the latency is even potentially visible (cusing one frame delay at 60fps).

Actually, this seems to be one of the terribly fuddy points from some of the Wayland team. But kernel latencies on IPC are very, very small and have been for years. Interestingly, there have been a few attempts (in the 90s) at protocol extensions for passing the entire protocol over shared memory to increase speed.

By 2000 or so, the improvement was so minimal that it was no longer worth pursuing further. http://dri.freedesktop.org/wiki/SharedMemoryTransport

If you have ever tried to get the window decorations to be "correct" (such as reliably knowing if there will be a close box so you can avoid having another method of closing the window) you would know just how much of an incredible horror server-side decorations are. Apparently you have not done this or just given up.

No, I am firmly of the user knows best and that programs should absoloutely not try to do things like that. I am continually having to add config lines to FVWM to override the stupid behaviour of programs which believe that they know more about window management than my window manager.

Client side decoration make it essentially impossible for the user to enforce any degree of sanity on the system and so the user is entirely at the whim of the application developer.

Please, PLEASE do not write programs which use hacks to decide whether or not to display a close button. Most window managers provide them. The ones that don't provide other mechanisms and the users of those certainly don't want you to give them extra GUI elements.

Basically server side decorations are only a horror for people who believe that they know better than their users. Client side decorations are a horror for the users.

No, Wayland is throwing out ALL X11 compatibility

As long as there's a widely available, free X11 server that sits on top of Wayland, compatibility isn't thrown out. And seeing as X.Org X11 and Wayland share a lot of developers, I fully anticipate that such a server will be maintained. From the FAQ: "we now run [X11 applications] under a root-less X server that is itself a client of the Wayland server. [...] With Wayland we can move the X server and all its legacy technology to a optional code path." Do you fear that this code path will bit-rot due to lack of test coverage as GUI toolkits are ported to Wayland and desktop Linux distributions make the switch?

I had one of those. Boiled it down to the smallest possible test case (AFAICT), even.

https://bugs.freedesktop.org/show_bug.cgi?id=35664

Couldn't tell you why it's still marked 'new', though.

From the documentation included in the Linux kernel tarball:

EXPORT_SYMBOL_GPL() -- Similar to EXPORT_SYMBOL() except that the symbols exported by EXPORT_SYMBOL_GPL() can only be seen by modules with a MODULE_LICENSE() that specifies a GPL compatible license. It implies that the function is considered an internal implementation issue, and not really an interface.

Also see http://lists.freedesktop.org/archives/dri-devel/2012-January/018273.html :

The controversy is about whether a module is a derived work of the kernel when you link it in. Traditionally, some modules were not considered derived works by a lot of people arguing that we have a public module interface that acts as a barrier for the license in the same way that the syscall interface lets you run proprietary applications. The EXPORT_SYMBOL_GPL is all about symbols that are too low-level to be considered part of that public module API (assuming that this API exists). The argument is that symbols which are not meant to be used in third-party modules can never be a license barrier and anything using them is a derived work even if you consider other modules not to be a derived work of the kernel. Note that this argument can still hold for low-level symbols that are marked as EXPORT_SYMBOL, using EXPORT_SYMBOL_GPL just makes it explicit.

Why, even read the original mail from NVIDIA themselves:

EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation issue, and not really an interface". The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead.

From the documentation included in the Linux kernel tarball:

EXPORT_SYMBOL_GPL() -- Similar to EXPORT_SYMBOL() except that the symbols exported by EXPORT_SYMBOL_GPL() can only be seen by modules with a MODULE_LICENSE() that specifies a GPL compatible license. It implies that the function is considered an internal implementation issue, and not really an interface.

Also see http://lists.freedesktop.org/archives/dri-devel/2012-January/018273.html :

The controversy is about whether a module is a derived work of the kernel when you link it in. Traditionally, some modules were not considered derived works by a lot of people arguing that we have a public module interface that acts as a barrier for the license in the same way that the syscall interface lets you run proprietary applications. The EXPORT_SYMBOL_GPL is all about symbols that are too low-level to be considered part of that public module API (assuming that this API exists). The argument is that symbols which are not meant to be used in third-party modules can never be a license barrier and anything using them is a derived work even if you consider other modules not to be a derived work of the kernel. Note that this argument can still hold for low-level symbols that are marked as EXPORT_SYMBOL, using EXPORT_SYMBOL_GPL just makes it explicit.

Why, even read the original mail from NVIDIA themselves:

EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation issue, and not really an interface". The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead.

There's an old, politically incorrect, cartoon with a husband freaking out in a car while his wife is driving the wrong way into oncoming , and saying, "I'm not going the wrong way... THEY are going the wrong way". Lennart Poettering wrote systemd, which is broken on machines with a separate /usr (without initramfs). Like the wife in the cartoon, his reaction is "My software isn't broken... the machines my software won't run on are broken. Repartition and reformat your machine.".

If that had remained strictly a Redhat-ism, nobody else would've complained. However, udev has been hijacked into the systemd tarball https://lwn.net/Articles/490413/ Because of the shared code with systemd, udev shares systemd's brokenness on machines with separate /usr, even if you're not running systemd itself. That's the vast majority of linux systems.

As the infomercials say... "But wait, there's more". Lennart Poettering has made no secret of his desire to do away with standalone udev. See
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Basically, if you want to use udev (required by the vast majority of linux machines) you'll one day need to switch to systemd.

There are scattered efforts to run systems on mdev, bypassing udev altogether.
https://github.com/slashbeast/mdev-like-a-boss#readme
https://wiki.gentoo.org/wiki/Mdev
https://wiki.gentoo.org/wiki/Mdev/Automount_USB

Opinion?

I'd like to see more vanilla versions of this software.

Well sure.

Here's the protocol extension: http://www.x.org/releases/X11R7.5/doc/randrproto/randrproto.txt

Here's the xlib API:
http://xcb.freedesktop.org/manual/group__XCB__RandR__API.html

Here's the command line tool:
http://linux.die.net/man/1/xrandr

And here are a bunch of GUI wrappers:
http://christian.amsuess.com/tools/arandr/
http://wiki.lxde.org/en/LXRandR

Which would you like?

Open Source Software has become almost as bad as the commercial counter parts in wanting to wrap everything up as one big GUI package. I don't want a bunch of bologna to download and run to configure dual monitors if I want to use a very lightweight window manager, or setup an embedded solution such as a kiosk.

Some times yes, but this isn't one of those cases. It's one of the nice really well designed parts, and not only that but any of those tools will work with any system. They modify the monitor layout, X sends a RANDR XEvent to the window manager and everything just works.

Two points:
 

if they have a sizable chunk of users it could work like the reverse of Microsoft's formats in the past. "Save that in .odt because everything reads .odt."

1) If it's Microsoft implementing Open Document Format, I guarantee they'll find some way to implement it subtely off-spec so that an ODF file created in MS Office will work correctly only when opened with MS Office, or an ODF file created in any other application will suffer degradation when opened in MS Office (like, for example, stripping out the formulas in spreadsheets). It simply isn't in Microsoft's DNA to play nicely with anything else. They are the Daleks of the software industry.

LibreOffice just won't bury the Office suite until Calc catches up with Excel.

2) Impress (the slideshow part of LibreOffice) is also going to need MASSIVE improvement before it will even be able to find the city that Powerpoint's ballpark is in. At the moment, you can't even use Impress for presentations with math equations, because the built-in LibreOffice math editor is buggy, clunky, and produces the ugliest math typesetting this side of a 1st grader's handwriting, and the LaTeX plugin option currently suffers from a regression in LibreOffice's svg handling (going back several versions) that corrupts the output.

Face it, Microsoft Office remains king for the forseeable future, and I've been watching the open source field long enough to suspect it will never muster the kind of vision, focus, and sustained drive necessary to topple that behemoth, no matter how many missteps MS takes or how complacent it gets.

Whenever this has happened the opens source fork wins (Mambo vs Joomla, LibraOffice vs OpenOffice - which then went open itself, etc.)

Actually.. for me, OpenOffice has won - at least in the Calc department. The LibreOffice devs have made several changes to bring LibreOffice's user interface closer to that of Microsoft products, losing superior functionality along the way, and being very inflexible on offering users choice within Libreoffice.

http://www.facebook.com/libreoffice.org/posts/120105584727720
https://bugs.freedesktop.org/show_bug.cgi?id=39438

Though truth be told this started in other areas with OO.o already, thanks to users screaming "Word does it this way, Excel does it this way" - perhaps the devs thought punishing those users by also copying inferior solutions was an appropriate response.

Your bug report goes here.

Actually, one thing they could have done in the journey from Gnome2 to Gnome3 could have bring to bring back the Networked Object Model Environment that defined the name GNOME. Somewhere along the way, they had dropped it, but since Gnome2 was fine, they could have left that part alone, and instead concentrated on the desktop object metaphors - maybe borrowing concepts liberally from GNUSTEP and any other OO UI. That would have been a lot more interesting and productive usage of their resources. The other things they could have done - write liberated video accelarators for the GPU, so that Gnome wouldn't need a fallback mode, Or look @ ways of combining the best of Qt and GTK into a single library. Or contribute to parts of the Freedesktop project. A lot of these are quite interesting projects that can leave developer morale high, w/o sabotaging the user experience of what already works.

> What people tend to forget about GNOME is that a large chunk of the developers are
> employed by Red Hat. GNOME isn't worried about losing users because regular users aren't
> supplying their pay cheques, Red Hat is and that's why they get to call the shots and you don't.

There must be some MS moles at Redhat, secretly working to destroy linux...

* GNOME 2 was usable; destroyed.

* Got your linux PC's hard drive nicely partitioned? Sorry, must repartition because they f'd up udev.

* Like your current init system (other than systemd)? Sorry, you'll soon have have to go with systemd as your init if you use udev. That's because udev code has been rolled up into the systemd tarball. http://article.gmane.org/gmane.linux.hotplug.devel/17392 At first they talked about long-term support for a separate udev. But they're rapidly changing their tune. See http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
======
(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't
noticed it yet. I am looking forward to the day when we can drop
that support entirely.)

Lennart

--
Lennart Poettering - Red Hat, Inc
=====

Some people are getting pissed off enough that they're seriously looking at running linux without udev. The common replacement is the mdev utility from the busybox build. See...
https://wiki.gentoo.org/wiki/Mdev
https://wiki.gentoo.org/wiki/Mdev/Automount_USB
https://github.com/slashbeast/mdev-like-a-boss
https://blog.stuart.shelton.me/archives/891

http://lists.freedesktop.org/archives/wayland-devel/2010-November/000037.html

With an X12 or X13, there would be the expectation of compatibility, which can't be wished away. With Wayland, they are starting w/ a clean slate w/ all the local capabilities of X plus some, and then for remote login services, the Wayland server can support a remote X11 client that still uses those protocols. That just leverages X11 for the X functionality that Wayland won't include, while having a clean implementation for just the essential stuff that Wayland will include

Just the opposite, the point of Wayland is to do LESS.

Start here: http://wayland.freedesktop.org/faq.html#heading_toc_j_8

In my experience, the hard parts of making GUI code are dealing with multiple platforms (why would you want to write code for a single platform?) and going from functional-but-dull to snazzy-and-usable. The networking side of things (or not) is nowhere on that map.

I don't write software where I have to push large numbers of frames through per second either. On the other hand I use software where large numbers of frames per second matter. Interestingly enough I just got the mac retina. Because the retina is doing virtual adjustments (i.e. there are several virtual screens being drawn to by applications and those those are re-rendered to another virtual screen which gets pushed to the physical screen) I could easily see frame rate problems in even day to applications like video inside a web browser while scrolling before the driver improvements in OSX 10.8. What Apple did in 10.8 to get rid of those problems, would be impossible under X.

Kristian Høgsberg who wrote a lot of the X acceleration you are probably using was the one who started Wayland. He was frustrated about what he couldn't do. Under X applications are not able to control rendering. They cannot make decisions required to avoid visible tearing. They cannot force the X client to draw potential windows in advance to avoid lag.

Another problem is either the client and server (to use X terminology) share a video memory buffer or they don't. If they don't you pick up a lot of time passing information between them. Your CPU is probably no more than a few gigabytes per second, that is the maximum speed you can get data from one buffer to another under best conditions. And with screens that are 5 mega pixel x 4 bytes of color per pixel, every one way trip is is 1/100th of a second under perfect conditions. You aren't getting perfect conditions and 2 round trips is common. And if X wanted to implement something like the resolution system Apple for retina then it would be worse (though the CPU speed for memory is likely about double) because you could be rendering virtual screens as large as 14 megapixel with some round trip being 4 hops.... you could be talking flicker over 1/10th of a second.

I hope these two examples help. They have a good discussion: http://wayland.freedesktop.org/architecture.html

The Wayland developers have repeatedly said they will support network transparency. Stop being a fucking drama queen.

Their FAQ disagrees with you:

Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland.

Well, No, yes and maybe. FAQ is useful. http://wayland.freedesktop.org/faq.html#heading_toc_j_8

Here's a method by which something similar might work in Wayland.

TwinView is the name of nvidia's implementation of multimonitor support.
If you need multiple monitores, nouveau supports this.

Anyway, my point was that users needing monochrome/EGA/CGA have no need for nvidia's binary blob.

For example some interaction between closed-source Flash and the closed-source Nvidia drivers turns people blue in Youtube videos but not other sites.

This is a known bug in Flash that Adobe refuses (or can't figure out how) to fix. There's a workaround you can apply: http://lists.freedesktop.org/archives/vdpau/2012-May/000022.html

There should be ways to detect the wirings and whether there is a mux and where, but the documentation is not available to the developers (maybe you can help us figure out how to do this, have any ideas? You can also 'petition' nvidia for releasing these specs: nvidia customer help ? )

However, AMD/ATI is a PR stunt. The drivers just wrap non-free software and can't be utilised at all on truly free software platforms.

Seriously? What do you think this is about? What's the licence on this that makes you think it's non-free? You seriously don't think this licence cuts it?

However, AMD/ATI is a PR stunt. The drivers just wrap non-free software and can't be utilised at all on truly free software platforms.

Seriously? What do you think this is about? What's the licence on this that makes you think it's non-free? You seriously don't think this licence cuts it?

... Some help is better than none.

Okay, so how about pointing him in the direction of the nouveau project? Even if his company refuses to share the full API, just a few hints here and there could make an enormous difference.

"An OS upgrade has no business resizing your /var or root partitions. Period. Heck, you have to be pretty ignorant if you presume they're always local."

An OS upgrade could conceivably slightly increase the amount of space used in /usr.

But according to this little gem /usr should now be part of your root partition. Which you will now presumably need to do an online resize of - assuming you actually installed your root partition on LVM, with the appropriate infrastructure needed to support that. Presumably, non-local /usr is no longer supported - similarly with having /usr (which is read-mainly) on a small SSD and the rest of the OS on spinning media.

Fuckup after fuckup after fuckup from Fedora these days. And an arsey attitiude from the likes of Poettering to go with it.

... there is the Nouveau free driver, it works very well for 2D stuff, but does not work for 3D stuff.

Then there is the NVIDIA blob driver, it works very well for 3D stuff, but works like crap for 2D stuff (and crashes).

So it depends on your requirements, and how wedded you are to the "Free" concept. Having said that, if there was a free driver that does 3D on Nvidia cards, I'd take it.

I'm not so wedded to 3D stuff as I am 2D stuff. You can figure out which driver is working for me on the NVIDIA based machines. If ATI ever gets REAL about playing well with Linux, it will get the "always buy that" recommendation. For now it's half-assed support with big problems vs. half-assed support with different big problems.

I have had to make a compromise in using the Nvidia driver. It's a "black box", so you don't know what is in it or how others might be able to improve on it, but on the other hand, it does the 3D work for stuff like KDE, Google Earth or 3D games like Brutal Chess or BZflag.

In Mageia, there is the Nouveau free driver, it works very well for 2D stuff, but does not work for 3D stuff.

So it depends on your requirements, and how wedded you are to the "Free" concept. Having said that, if there was a free driver that does 3D on Nvidia cards, I'd take it.

Proper place in the file system hierarchy? Assuming its some place in /opt, modifying the path?

Well, on Windows they install all games under %ProgramFiles%\Steam\steamapps. On Linux, the equivalent would be /usr/share/steam.

There's no need to modify the path, so long as icons / menu items reference the binaries using full path. If the user wants it, they can always add the game to the path themselves. If they really wanted to make this work, they can create /usr/steam/bin, update /env so that this is in PATH (or ask user to update themselves), then symlink game binaries there.

Icons for popular desktops (or just some?) Integration with the universal menu system?

We have standards for that for several years now. KDE and Gnome both support it; IIRC, so does Unity and XFCE. Fluxbox users probably don't care in the first place.

Of the eleven supported archs seen on debian.org/ports, and twenty three supported plus unsupported archs, which will steam support? Sadly I'm guessing i386 only, not even amd64.

They'll probably support any architecture that runs x86 binaries - meaning i386, or amd64 with i386 compat. Which in practice is 99% of Linux desktops out there.

As a company, nVidia doesn't play too nice with free and Open Source software. Then again, they don't sue the pants off the software developers either, so you can mod them neutral. But enough reverse engineering has been done to make most (save the latest and greatest) nVidia powered graphic processors run fairly well using non-proprietary drivers.

Moving every thing to /usr to make the filesystem more sane.

Meaning that the system no longer supports /usr in a separate filesystem: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.

Of course, you can still use /usr in a separate filesystem from / if you boot with an initrd, but you now almost need half an operating system (busybox, rescue shell and utilities, perhaps support for lvm and/or RAID) just to boot your real operating system.

Why would you want /usr on a separate filesytem? Perhaps you want it in LVM, so you can resize it easily if necessary (maybe to make room for installing a new desktop environment, for example), but don't want you root file system in LVM. Perhaps you want to periodically fsck /usr on boot, and fall into single-user mode if it fails. Perhaps you want /usr (which is a read-mainly file system) on a small SSD, and all other file systems (which are written to more frequently) on spinning disk storage. Perhaps you want to mount /usr over NFS. Not that I can still see many people doing this but it seems a pity to prevent something that has worked fine in the past - and in these days of "running applications in the cloud" it seems Linux will no longer run applications in the local network (ie. NFS-mounted /usr).

Seriously, read the level of professionalism and maturity on that page. This is the level or maturity to which Linux slowly seems to be sinking. As a long-time Linux user and supporter I find this deeply disappointing.

And what's the reason for all this? Because the udev developers can't wipe their own a{r|s}es, put their house in order, and properly sort out which files go where (or at least sort out what needs to be done to mount any necessary non-root filesystems, mount them, and then continue with any programs/scripts which use them). Instead, all of that gets pushed out to initrd (ie. oh no it's hard, let's give it to someone else to do). Seriously, they're like a bunch of 8-year-olds bragging to their friends that they won't clean their bedrooms, even when mummy thinks they should.

We embed these in our Atom-driven products to run GUIs and they work like a champ.

Mimo 7" USB touchscreen = $180

Mimo 10" USB touchscreen = $260

We use NT embedded but these also have OSX drivers, and if you want to use these with Unix you're not alone.

The recently released (11th May 2011) Pulseaudio 2.0 lists improved jack detection as one of its features so you will probably be waiting longer for a fix to show up in a non-rolling distro...

I've got a great reason that I'm downloading openoffice right now for. It's this issue. In a nutshell, many moons ago Excel changed their selection rules behavior for no explicable reason and every other spreadsheet on the planet has been copying their behavior. When you call the developers on this, like the guy who submitted this bug report, the developer response is "everyone else does it this way so I won't change it". If Libreoffice is going to strive to be the best clone of Excel that it can, why would I use it? Given the choice, I'll just use Excel. Maybe the Apache version of OO.org still has some distinct behavior instead of just being a clone of something else.

If you have eight channels... it sounds like at least a semi-serious setup. But if you are using Cobra net, you'll definitely be putting time into troubleshooting and maintaining that kind of a beast. Why not just buy some good new fashioned Airport Express devices to stick into each room, and broadcast the audio through there, maintaining it through iTunes? It would save the value of your time... which you could then for other stuff.

Otherwise, get a Linux box, and stick some PulseAudio on there -- http://www.freedesktop.org/wiki/Software/PulseAudio

But you'll have to tinker more, which it sounds like you kinda want to do.

I can't speak of the totatlity of VMware software being open source or not.

However, the Linux 2D/3D driver is open source http://cgit.freedesktop.org/xorg/driver/xf86-video-vmware
It is also available in the recent Linux kernel releases.

http://nouveau.freedesktop.org/wiki/FrontPage

Maybe this?

Or this perhaps: http://nouveau.freedesktop.org/wiki/HardwareStatus

From what I've read 2D *is* faster for many of the cards but not all, and only notably so for the older ones that Nvidia has shuffled off to their "legacy" driver. 3D, from what I have heard, does not work at all on most cards, and is massively slower across the board on the few older cards for which there is some minimal support working thus far.

Maybe my information is out-dated now but I would say if you have archaic Nvidia hardware (AGP-era and earlier) then this driver may be a breath of fresh air for you as far as features (KMS support, woo-woo!) and 2D application performance. For all other purposes... eh, I'd say the future of this project shows promise but it could use some generosity from Nvidia of the same sort they provided for the forcedeth ethernet driver.

http://nouveau.freedesktop.org/wiki/FrontPage

Maybe this?

Or this perhaps: http://nouveau.freedesktop.org/wiki/HardwareStatus

From what I've read 2D *is* faster for many of the cards but not all, and only notably so for the older ones that Nvidia has shuffled off to their "legacy" driver. 3D, from what I have heard, does not work at all on most cards, and is massively slower across the board on the few older cards for which there is some minimal support working thus far.

Maybe my information is out-dated now but I would say if you have archaic Nvidia hardware (AGP-era and earlier) then this driver may be a breath of fresh air for you as far as features (KMS support, woo-woo!) and 2D application performance. For all other purposes... eh, I'd say the future of this project shows promise but it could use some generosity from Nvidia of the same sort they provided for the forcedeth ethernet driver.

http://nouveau.freedesktop.org/wiki/Development
I'm no engineer, not even a reverse engineer, but I'd probably start with a bus analyzer, gdb, and follow some kernel/driver debugging lists.
Dear reader, feel free to tell me how wrong this approach is.

According to TFV it is easy to add network transparency to wayland. They just haven't done it yet.

But the wayland FAQ says that it is a fairly complicated task
http://wayland.freedesktop.org/faq.html#heading_toc_j_8

Which is right and which is wrong?

One of the features that always distinguished X from other display systems like Mac and Windows has been network transparency. You can ssh to another Linux system, start an X application, and that X application will appear on the system you ssh'd from. This is immensely useful and evidence of a well-thought-out design, but it's an afterthought to Wayland. They say they might be able to render to a VNC server, but VNC works like crap and is full-desktop forwarding rather than individual window forwarding.

It's extremely ironic that when X was created in the 80s they recognized the importance of distributed systems and network transparency, but now it's 2012, the Internet and the cloud is king, yet network transparency isn't a core feature.

All this because you can't cross-fade when switching VTs in X or have a "rotating cube" animation (see "Is wayland replacing the X server").

This move was not unexpected. We've been hearing things to this extent for a bit now.

This leaves a few questions. First of which is:

Are the open source alternatives ready for prime time? Correct me if I'm wrong but here is the list of the major alternatives:

1. Gnash
2. Lightspark
3. Swfdec

4. 1. I've included Swfdec, but as I understand it, this is for flash apps that you have created and know work with swfdec. It is not for random content from unknown sources. A use case for this is a kiosk where you control the content and the display.

      Now, are the other two, Gnash and Lightspark, ready for primetime, i.e. can they replace Flash Player any time soon?

      Personally, the last time I used either one was a few months ago when I toyed with the idea of trying to make my workstation fully open source. I found that many youtube videos made the plugin crash for both Gnash and Lightspark.

      Since there is content right now that is made for Adobe's Flash Player, I feel that the way forward should be to stop creating new content for Flash. Let it die, and only create new content in HTML5. As for the existing content, the alternatives like the ones listed above need to be able to play need to be able to play it with no problems. I would even have no problem if there was new content developed with the alternative in mind rather than close source Flash Player.

There's still a problem with Llano VGA in Linux 3.3. These bug reports seem to indicate that the problem lies with the DP to VGA bridge not working. As a workaround, you can use a HDMI/DVI connection instead of VGA.

http://wayland.freedesktop.org/

A developer has already stepped up to implement one of these. This is why I love open source.

https://bugs.freedesktop.org/show_bug.cgi?id=46070

https://bugs.freedesktop.org/show_bug.cgi?id=38542 & 42750

There was new feature added that completely changed how 'Table>borders>styles' is configured. A patch was made to fix backwards compatibility, sort of, but new border styles are not useful.

Not a fan of dev's run wild. I do not see the value in the metrics of the number of new code changes to software that works. New code new bugs, ad infinitum.

I switched to Apache OO 3.4-dev, it works fine, I don't feel I am missing any new' features...sometimes when something works...leave it alone.

Open bugs with that feedback.

Done! Please subscribe to the bugs and leave comments so it is not just me saying "this would be nice".

Remember last background colour
https://bugs.freedesktop.org/show_bug.cgi?id=46069

Copy cell above
https://bugs.freedesktop.org/show_bug.cgi?id=46070

Open bugs with that feedback.

Done! Please subscribe to the bugs and leave comments so it is not just me saying "this would be nice".

Remember last background colour
https://bugs.freedesktop.org/show_bug.cgi?id=46069

Copy cell above
https://bugs.freedesktop.org/show_bug.cgi?id=46070

Great, a major LO upgrade. That means I download it, install it, and see how many minutes it takes me before I hit a large enough Office compatibility snag that makes me delete it and swear off giving it another shot.

Instead of swearing it off, get in touch with me and we will file bugs. Sure, it might take a year or three until they are fixed, but most of them _do_ get fixed in LibreOffice. I would say that the last year in LO has closed more of my bugs than the past five years of OpenOffice.org, including one very critical bug that has been open for almost _ten_years_:
https://issues.apache.org/ooo/show_bug.cgi?id=5556

Fixed in LO six months after filing:
https://bugs.freedesktop.org/show_bug.cgi?id=37978

You can contact me here, please have a file that demonstrates the issue handy or clear reproduction instructions:
http://dotancohen.com/eng/message.php

Thanks.