If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

SteamOS will be PERFECT for that in special because it's NOT a regular Linux distro where you can use LibreOffice,etc.

At 1st glance is disappointing but will save Valve from a lot of customer service problems with stupid users used to use a stupid console like PSx or XBOXxxx.

I don't think anyone sane wants to use desktop ui or LibreOffice in their TELEVISION. It has nothing to do with stupidity.

I have big mythtv setup in my house and running any desktop environment in frontends would be very bad user experience. Using desktop when relaxing in livingroom (after working with computers for a day) would make me cringe.

Comment

In your previous message, you said that "I am pretty sure valve will not even have a display server installed on SteamOS, has SteamOS is intended to run one software in full screen and everything else is an overlay on top of it, so will most likely use the frame buffer for optimum performance. "

The AMD and nVidia OpenGL drivers require X.org (which is a display server) and expose OpenGL via an API called GLX ("OpenGL Extension to the X Window System").

I never said they couldn't draw into an FBO... I just said that the drivers necessary to anything beyond fbdev depend on X.org. With desktop hardware and the proprietary drivers they've put so much effort into improving, accessing OpenGL without a display server is less of a supported configuration than Weston is.

Should read your own link, notice the nice direct rendering path, the OpenGL API is missing a fork toward direct rendering path for the proprietary libGL.

Comment

I guess Steam Big Picture will be the only User Interface accessible without hacks . . . i hoped it will be a fully usable computer but it's just another console.

Then you don't understand what SteamOS is all about. From my understanding, SteamOS is all about creating a standard Linux stack for game developers and hardware manufacturers. In other words, developers and manufacturers just need to target SteamOS instead of worrying about different distros. Any special improvements Valve makes to the kernel or the graphics stack will be merged back upstream from my understanding (they did that with improvements they made while porting Left 4 Dead 2). In other words, you should be able to get SteamOS experience using Steam client on any distro, but for the unexperienced they just need to buy a ready made Steam Machine.

Comment

Should read your own link, notice the nice direct rendering path, the OpenGL API is missing a fork toward direct rendering path for the proprietary libGL.

The link to the GLX page on Wikipedia? I've read it in full. Just because GLX supports direct rendering doesn't make it trivial to bypass the X11 side of things entirely. Direct rendering is only available once X.org has initialized the driver and been used to set up initial communication between the driver and the application.

Have you ever tried running games in Wine and tripped over a crash-inducing bug? It's a similar problem but in your video drivers. The drivers aren't designed to work without X.org so, unless you can fake X.org's ABI convincingly enough to manage initialization and lie about desktop status, you can't use them and, if you make even one mistake in impersonating X.org, the video drivers will crash due to a violated expectation.

(I get the impression you're not a programmer. As a computer science major who's been programming since the age of 8, let me assure you, there's nothing more fragile than native code which only compiled successfully because the compiler was checking against a different implementation than the one you're running with. A crash isn't actually an application saying "I give up!", it's the kernel killing the application for trying to perform an invalid action. For example, a segmentation fault us the application trying to access memory outside what was assigned to it... often at address 0 which is reserved to mean NULL in C.)

To get around that, nVidia, ATi, and Intel would have to make, test, and release custom versions of the drivers... and it would be more work than the XMir patch Intel just rejected. (And probably at least as much work as the MIPS recompile nVidia wanted an arm and a leg for which lost them a 10-million machine bid to ATi in China.)