Linked by Kroc Camen on Mon 24th Aug 2009 13:09 UTC
Podcasts

Linux user Tess Flynn joins us to follow up on the feedback from last week's episode about Xorg.

Download .mp3 | Subscribe in iTunes | Subscribe RSS

Thread beginning with comment 380576
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Difficult and complicated
by jjmckay on Tue 25th Aug 2009 20:31 UTC in reply to "RE: Difficult and complicated"
jjmckay
Member since:
2005-11-11

jjmckay - the problem is that yes, XOrg is complicated. But the reason XOrg is doing so well these days is because they *don't* tell people to mind their own business. I could talk about the bad old days of XFree86, but that's getting on to another topic.

You shouldn't have to muck around with xorg.conf now, and you REALLY shouldn't need to mess with modelines. Every monitor made in the last 10 years has EDID, and will tell X what it supports. Unfortunately, there is still a lot of old information on the internet. If you modified your xorg.conf, it will take that as the word of god, so if you removed a monitor, it will still act as is it is there.

The best thing users can do is to make sure there are more developers on X. XOrg is getting by with such a skeleton team of devs, it is unreal.

How I would suggest getting more developers .. pointing people that know how to write code and want a challange to XOrg; make sure Google SOC money goes to X; make sure distros that have money to spend know to spend it on X; donate money; get other users together and make payouts for developers doing work on X.


Thanks for the thoughtful reply. Well that's the thing, when I look at Firefox and how well it's doing and how there's no big need for users to try to get developers involved in developing Firefox because there seems to be a lot of interest because firefox inspires developers to code for it without much need for users to advocate for it. On the other hand x/xorg doesn't seem to be inspiring people to code for it, for whatever reason I don't know. Maybe doing graphics work is top dollar high paying work and doing a massive graphics system overhaul is not something that's going to happen for free and by itself, unlike a new ls command.

I care, yes. But the issues I see with the basic model of how unix/linux does GUI's seems antiquated from a local desktop perspective. In the 1970s we had the mainframe mentality and that was fine, but technology evolved. Sure, many admins still use remote x sessions and it's efficient and elegant for that. (I love ssh2'd x sessions, hehe)

I have a basic model idea of how xorg needs to evolve or be replaced. The idea is similar to what happens with Direct3D on Windows where instead of evolving and adapting new techs to through old ideas, they just walk around the old tech and develop something new.

More specifically, lets say KDE could use an alternate rendering path, call it xorg3d v1. Then any app that assumes it's using x is actually tunneled by the kde renderer (or compositor) through the new path (system calls, etc) that uses a local framebuffer or whatever is needed. Yeah, my knowledge is limited but I think the idea might point to what needs to happen. For all I know, this has already been done, I don't know, but I've never heard of Gnome or KDE being able to use any other display route than x/xorg, except perhaps compiz but I think even that still hangs on to legacy stuff from x. I don't know.

Just like how the KDE guys have redone it from scratch, so too does unix/linux land need to start over, for the sake of the desktop users. I don't see why it can't be done so that it is compatible and invisible to apps that assume x/xorg.


Note:
I had no xorg.conf when xorg broke after removing the powered-off second display (the crt) so I'm sure I didn't break xorg. By default F11 doesn't have an xorg.conf. I have yet to copy a skeleton type xorg.conf into the right directory so I've not put a new xorg.conf there yet.

Reply Parent Score: 2

siride Member since:
2006-01-02

Yes, your knowledge is limited. There are alternatives to X (or have been), some of them still around, like DirectFB. Many GTK+ applications can supposedly run directly on the framebuffer. But you know what? X is still the best solution around. It actually does work pretty well, so much so that no alternative has ever been able to show up as more than a blip on the radar. Even now that X is basically opening up video mode setting and direct rendering to the rest of the world with KMS and related changes, I see no big projects that are making use of those to build a new, more efficient rendering system. If a new rendering system is so self-evident and so very much needed, then surely enough people would be working on it. I mean, other forks and replacement projects have proceeded just fine (GNOME came about to deal with the licensing problems of Qt and now it is arguable the stronger of the two desktops).

So the reality is likely that X really is fine in most regards. It needs some polish and a few more old bits need to go away. No doubt about it. But as a rendering system, it does the job just fine. And, as I surmise, the real problem is in the toolkits and the DEs, which fail to provide an integrated and stable platform for applications.

Reply Parent Score: 2