xfree will be the best....

Hi my name is Alessandro....
sorry for my bad english...but I WOULD LIKE TO explain my opinion.

I REALLY LOVE linux + Xfree but for THE desktop
domination, IMHO, the way to follow is: 

1- To remove the client - server comunication protocol of Xfree, to have 
after less context switchings and also less parameter copies in shared memory.
see link :

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarwbgen/html/msdn_movuser.asp
The network comunications isn't necessary because the 90% of computers in the world don't use it. ( like windows ).

2 - the direct access of the applications have to write only on mmio registers of the graphic acceleration engine or direcly
in the frame buffer memory.

see directfb :

http://directfb.org/documentation/DirectFB_overview_V0.1.pdf

There is no overhead of system call to write in the graphic acceleration engine.
My idea is to implement Xfree server as a library, which can be used by all the applications.

3 - to replace user space inizialization drivers of Xfree with the kernel inizialization drivers
( only colors and resolution settings as like fbdriver )
In this way there is no code duplication in Xfree and in the linux kernel.
( pci functions in xfree will be replaced by pci functions in linux kernel...etc)

The capabilities of the driver are sent to the application running in user space by the linux kernel.
In this case there is no needs of speed...I can use the system's calls and there is less used memory .
There is no necessary to implement a drivers' loader for xfree, I can use the same kernel's modules'
loader.

4 - I don't want reinvent the wheel, so it is necessary to replace all kernels
fbdrivers  with a kernel fbxaadrivers as :

fbconsole
    |
   xaa ( xaa tiny interface, only for accelerate caratters handling )
    |
   ddx ( ddx tiny interface, only for initialization graphics hardware, capability, and mmio accelerate registers.)

In this way the kernel will support the same
graphic cards of xfree.
The kernel will boot with a simple graphic active mode
( only colors and resolutions and caratters.)
no graphic mode switching within  console and the windows system.
It is only necessary to repaint the screen by accellerate xfreedriver in user space.( like directfb )

5 - with a small part of the graphic drivers in the kernel, we can detect the 
interrupts, as vertical blanking of the video card or the dma comunication,or something else.
In this way we can send a signal to a process in user space ( in particular at the windows manager ) for other things.
This process ( WM ) will send the signals to other
processes for windows operations. In this way the central process  will be the windows  manager and not the Xfree server because
it doesn't exist.)

6 - to replace the Xcore render, with Xrender and RandR
extensions, and on the top of the Xrender we don't want to use the xlib but the win32 graphic api.

I think so because:
- Xrender is faster than Xcore render.. ex. antialising.
- xlib is obsolete and not multitread
- with win32 graphic api we will replace the interface of xlib api layer
..but not for the compatibility with the applications ( gtk is compatible with win32 , qt is compatible with win32 )
- the WINE application will be much more faster.

 win32
 |
 Xrender + ( tiny xlib??? )
 |
 dix
 |
 xaa
 |
 ddx

7 - The lock to access to the  graphic hardware will be done with the same idea of the
    sarea ( DRI ) in user space ( not overhead of the system's calls ).
    I want to use as possible the same code of the DRI .


I'M WAITING FOR YOUR KINDLY COMMENT

Ing. Alessandro Camela.



______________________________________________________________________
Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino
http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html