Can't X be elemenated?
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
2. On top of that, one can develop complete lightweight GUI.
3. Maybe kernel can provide support for event handling.
and I still stick to my opinion that graphics card is a computer resource that needs to be managed by OS rather than 3rd party developers. Just feeding in patches to provide support for AGP gart and DRI is an adhoc solution, a stark immoral choice.
you don't know my frustration when i got PC and wasn't able to run X until i810 agp gart support was available at kernel level.
And if you feel that I am a guy heavily dependent on X that's not true.
I just mean to say if anything is that kernel level support for graphics device drivers. And X will be automatically eliminated.
and if you are feeling very unhappy about my statement X is bloat, I really apologize for that.
Quoted 85 lines
From: Paul Jakma <[email protected]>
To: kartikey bhatt <[email protected]>
CC: [email protected], [email protected]
Subject: Re: Can't X be elemenated?
Date: Tue, 30 Sep 2003 19:48:22 +0100 (IST)Quoted 1 line · kartikey bhatt
1st. X is bloat.
This isnt true.
[paul@fogarty paul]$ cat
/proc/pidof X/status | grep ^VmVmSize: 47700 kB VmLck: 0 kB VmRSS: 22580 kB VmData: 25540 kB VmStk: 72 kB VmExe: 1488 kB VmLib: 1580 kBX is actually quite tiny, ~3MB of exe+lib. The data size is due, vastly, to the X /clients/ using the server (in the above case RH9 GNOME + windowmaker + xchat2 + galeon + few xterms).
Here's Xipaq (tinyX handheld X server):
~ $ cat
/proc/pidof Xipaq/status | grep ^VmVmSize: 5072 kB VmLck: 0 kB VmRSS: 3164 kB VmData: 1788 kB VmStk: 16 kB VmExe: 848 kB VmLib: 2028 kBThat's Xipaq, exe is smaller, but libs are bigger, balances out to ~3MB again. However, the data segment is much smaller, < 2MB compared to > 25MB for the desktop case. The handheld runs the GPE
(http://gpe.handhelds.org) environment.So perhaps you could come to the conclusion that 'X' (in the X server sense) is not bloat, but that the /clients/ on modern desktops are?
Quoted 2 lines
Though it's good for server environments. For desktop pcs it's too heavy.
You are misinformed. See above.
Quoted 1 line
2nd. It's process based client/server architecture is a bottleneck.
Why do you think so? For large amounts of data, X clients can use shared memory. Further, even if they must transfer data (ie pixmaps/pics) across the socket connection, the X server can cache it, and the client can use it by reference. (ie a once off cost).
Also, local X clients use unix sockets - blazingly fast.
Quoted 1 line
It's not as interactive as is supposed to be.
Have you tried 2.6.0-test6? The interactivity problems were the kernel's fault more than that of 'X'.
Quoted 3 lines
3rd. Most important. I can't impress or convince my window(crash)(TM) user friends, relatives (who saw X running on my pc) to use Linux.
You wont impress /anyone/ with "just X" (ie just the X server) - cause all you'll get is a tiled background of tiny X logos and an X mouse pointer.
Quoted 1 line
4th. I want to see desktop being ruled by Linux.
"X" isnt the obstacle.
To be able to constructively criticise something you first need to /understand/ it. You dont.
Most of you what you complain about, bloat and heavyness, is due to the desktop environment - not X itself. Try running GPE
(http://gpe.handhelds.org) or (easier/actually practical too for a desktop) Xfce (http://www.xfce.org)Finally, this isnt a kernel problem.
Quoted 12 lines
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
warning: do not ever send email to [email protected]
Fortune:
Real wealth can only increase.
-- R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
_________________________________________________________________
Get Married! http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Search from 7 lakh Brides & Grooms.
Quoted 4 lines · kartikey bhatt
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
Done
Quoted 1 line
2. On top of that, one can develop complete lightweight GUI.
Not relevant to this list
Quoted 1 line
3. Maybe kernel can provide support for event handling.
Why?
-Tupshin
Quoted 4 lines · kartikey bhatt
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
Ok.
Quoted 1 line
2. On top of that, one can develop complete lightweight GUI.
don't want it in the kernel (bloat)
Quoted 1 line
3. Maybe kernel can provide support for event handling.
already does.
Quoted 11 lines
and I still stick to my opinion that graphics card is a computer resource that needs to be managed by OS rather than 3rd party developers. Just feeding in patches to provide support for AGP gart and DRI is an adhoc solution, a stark immoral choice.
you don't know my frustration when i got PC and wasn't able to run X until i810 agp gart support was available at kernel level.And if you feel that I am a guy heavily dependent on X that's not true. I just mean to say if anything is that kernel level support for graphics device drivers.
And X will be automatically eliminated.
don't need it/already done in the frame buffer.
You CAN also look at the GGI project (http://www.ggi-project.org/)
They have an interesting approach (only slightly superseded by the framebuffer driver) - They are/were looking at dividing the graphics resource into its' components. Clock drivers, video registers drivers, GPU interface drivers, graphic event queue driver. Last time I was looking (shortly after the framebuffer introduction) they wanted to be able to mix and match the components to the actual devices on the video board (since many of them use the same fundamental components) and eliminate the "one driver one video device" aspect.
It may even be suitable for embeded devices... though I think they kinda got too large since then.
They also support X.
Quoted 2 lines
and if you are feeling very unhappy about my statement X is bloat, I really apologize for that.
Not unhappy, it just indicated a bit of experience lacking.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 1 Oct 2003, kartikey bhatt wrote:
[...]
Quoted 1 line
2. On top of that, one can develop complete lightweight GUI.
I wonder how such a move would impact the users of other free OSes like FreeBSD. They use the same X afaik.
I think you might get locked into this new gui like in the trap. X is not lightweight but it is kind of universal. This means, you can get app written originally for Solaris or SGI and in most cases you "just recompile" it and it's available on Linux. Just like this. And if you started forcing new gui, some people would stay with X and some would switch - all of this might do nothing good to growing the number of applications that could run on Linux.
Such a lightweight gui is nowadays needed only on some very specific platforms, IMHO. Those with less memory and cpu, like handhelds and other embedded applications.
Think of MS Windows family - they are a real bloat but they are more or less unified. Not that I admire the way MS did it but I think I can still run 16-bit apps on Win 2000 (if I really wanted to trash filesystem with old dlls). This ability to accumulate applications over long period of time shouldn't be discarded. In reality, you would probably have ended with a small number of people using lightweight gui and the rest of people staying with X, which has better support and good number of developers. Right now, the only real alternative is - in my opinion - QTopia/QTEmbedded/Opie. You can try to run this on your PC (I think I have read somewhere on the net it is possible).
If, on the other hand, you would like to see what happens to less used guis, try looking on this:
http://hack.org/~mc/mgr/index.html
MGR has nice minimalistic look but isn't in very active development today. Guess why? It aimed to be 10x faster than X for example, but today hardware has more power and X has improved too.
On the other hand, if all you need is terminal emulator and some other similar apps, you may find what you are looking for. But I really think all of your problems come from some badly written driver or an app eating too much memory. Not X as a kind of gui but poor implementation.
[...]
Quoted 2 lines
you don't know my frustration when i got PC and wasn't able to run X until i810 agp gart support was available at kernel level.
You know, while waiting for the support to come, you can use some cheap old pci card. I have seen used Matrox Millenium 2 for about $4. I myself use mm2/agp and it gives me great desktop, excellent for reading and writing texts and watching tv. Just enough power to work. Very stable, sharp etc. On the other hand they tend to be treated like a trash because of not having support for all these fancy 3d things.
And next time before buying a mobo, try to ensure it is already supported under Linux. The same applies to onboard sound and ether.
[...]
Quoted 2 lines
and if you are feeling very unhappy about my statement X is bloat, I really apologize for that.
I don't feel unhappy with this but I think you can do much better - since my old matrox w/4m ram has no problems with handling me without hickup.
How about trying some development version of X from CVS? Or asking about your chipset on X-related newsgroup?
bye
T.
- --
** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:[email protected] **
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBP3schBETUsyL9vbiEQLznQCdFxF3xMja6bp667Jw9oVLV4hnjp4AoPYo YYl31jQtxtTzloiBZmb1yzdw
=iZ5a
-----END PGP SIGNATURE-----
Quoted 9 lines · kartikey bhatt
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
2. On top of that, one can develop complete lightweight GUI.
3. Maybe kernel can provide support for event handling.and I still stick to my opinion that graphics card is a computer resource
that needs to be managed by OS rather than 3rd party developers.
The card is managed by the os - X has to ask the kernel nicely to get it. (Try starting another X server inside an xterm and see how that is refused.)
The details of drawing the windows is something the os don't need to worry about though - that is the job of X.
Please explain whats wrong about "3rd party developers". Depending on how you look at it, all of linux is "3rd part developers" except from Linus.
Quoted 2 lines
Just feeding in patches to provide support for AGP gart and DRI is an adhoc solution, a stark immoral choice.
Explain the immoral part. Committing a crime is (usually) immoral. Designing software in a way you dislike isn't.
Quoted 3 lines
you don't know my frustration when i got PC and wasn't able to run X until i810 agp gart support was available at kernel level.
So?
Having graphichs in the kernel would *not* change this at all. You would still have to wait for graphichs support for your card. The kernel would still have to support i810 agp gart.
Linux doesn't support every graphics solution in existence. That is a fact of life. Wheter the missing part is in kernel or somewhere else doesn't matter at all. It either works or it don't.
Quoted 4 lines
And if you feel that I am a guy heavily dependent on X that's not true.
I just mean to say if anything is that kernel level support for graphics device drivers.
This sentence didn't make sense to me. Syntax error? :-)
Quoted 1 line
And X will be automatically eliminated.
Sure. Having the kernel provide graphichs would eliminate X, if the kernel would support all the stuff X supports. But whats the _point_ of eliminating X?
1. It wouldn't be faster
2. You wouldn't get support for more cards this way
3. It wouldn't be better in other ways either
Using X for graphichs is nice however, for several reasons:
1. Separation of kernel and graphichs system. This means we can trivially run without graphichs if we don't need it. And yes - there are many such uses for linux. The desktop is merely one of many places where you find linux.
2. There would be fewer graphichs developers for linux with the graphichs in-kernel. Today X is used not only by linux people, it is also used by other unices like bsd, and others too. A bsd/os2/... X developer working on X today will benefit linux too. That won't happen with a graphichs system internal to linux.
Helge Hafting
Quoted 8 lines · Helge Hafting
Quoted 7 lines · kartikey bhatt
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
2. On top of that, one can develop complete lightweight GUI.
3. Maybe kernel can provide support for event handling.
Quoted 6 lines
Quoted 2 lines
and I still stick to my opinion that graphics card is a computer resource
that needs to be managed by OS rather than 3rd party developers.The card is managed by the os - X has to ask the kernel nicely to get it. (Try starting another X server inside an xterm and see how that is refused.)
X :2 (not refused ...)
Quoted 11 lines
The details of drawing the windows is something the os don't need to worry about though - that is the job of X.
Please explain whats wrong about "3rd party developers". Depending on how you look at it, all of linux is "3rd part developers" except from Linus.
Quoted 2 lines
Just feeding in patches to provide support for AGP gart and DRI is an adhoc solution, a stark immoral choice.
Explain the immoral part. Committing a crime is (usually) immoral. Designing software in a way you dislike isn't.
depends on the moral standards ...
best,
Herbert
Quoted 13 lines · Herbert Poetzl
Quoted 12 lines · Helge Hafting
Quoted 10 lines · kartikey bhatt
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
2. On top of that, one can develop complete lightweight GUI.
3. Maybe kernel can provide support for event handling.and I still stick to my opinion that graphics card is a computer
resource that needs to be managed by OS rather than 3rd party
developers.
Quoted 5 lines
Quoted 3 lines
The card is managed by the os - X has to ask the kernel nicely to get it. (Try starting another X server inside an xterm and see how that is refused.)
X :2 (not refused ...)
Thats because X asked nicely, and was given another vertual terminal, and started server #2... By default it attempts to start 0; and that is refused.
Specifying a different server number will permit it to be run, if there are available VTs.
You should be able to run at least 7, if they don't have login prompts on them.
Quoted 9 lines · Helge Hafting
Quoted 7 lines · kartikey bhatt
hey everyone who have joined this thread, my fundamental question have got out of scope. I mean to say
1. Kernel level support for graphics device drivers.
2. On top of that, one can develop complete lightweight GUI.
3. Maybe kernel can provide support for event handling.
Quoted 7 lines
Quoted 2 lines
and I still stick to my opinion that graphics card is a computer resource
that needs to be managed by OS rather than 3rd party developers.The card is managed by the os - X has to ask the kernel nicely to get it. (Try starting another X server inside an xterm and see how that is refused.)
that has nothing to do with kernel. If you are running display 0 and
start another X (without specifying display, it default to 0) it doesn't work since there cannot be two servers on same machine both being 0. You can start another X server with different number (e.g. startx -- :1 or whatever number is not used yet).
erik