Re: [coLinux-devel] Re: coLinux graphics

[Henry N. <Hen...@ar...>]

Hallo,

I wrote some linux low level device driver, such also a FB for hardware 
that have no real Video RAM. For Win32-Memory-API I am not know all 
technics.

You say, you can share real physical memory from Windows?
That's very nice!
Give colinux kernel the information about Windows video RAM and coLinux 
FB runs. Linux need a small FB modul, in this must only wrap the init 
function and gif coFB the informations about Pixel-Mode (colour deep).
As step two: coFB can wrap acceloration functions.

The performance should be excellent, because memory transactions from 
linux to windows no need. (In comparing with LAN)

On linux side no SDL need.

On Windows side SDL Win32 give a good startup for framebuffer functions. 
But SDL Win32 can have not all functions for FB. SDL based on update a 
reactangle area. "SDL" I have only say, than we should also find a way 
to direct write into video RAM on Windows client area.

"Cut and Past" should be handle via GPM. How do putty handle this?

What is the applicatoin, that I should start for UML drawbacks?
Sample: I am booting real linux with FB. I am using FB for X11. Now I 
run a UML kernel and linux. But what is the application to have a 
graphic box with running FB in UML-kernel?
	I am stupid. UML = user Mode Linux?
I know this only as a text box for kernel boot messages, and many other 
text boxes on pts devices.

Henry


Digital Infra, Inc. wrote:
> First, Lucas, Thank you for good summary.
> ( I am not sure which to use  --- Nuno or Lucas.)
> 
> And folks, to make the discussion useful, please refer the log
> before you post something.
> http://marc.theaimsgroup.com/?l=colinux-devel&m=108920889621282&w=2
> 
> And my opinion for Lucas's posting is,
> 
> About FB or not FB:
> As my opinion, I am for FB. Yes, Lucas is right. The fundamental matter 
> depends on how fast a virtual ether connection is. But even it getting much 
> faster, I think FB has its value.
> the reasons are:
>   - FB is always faster.
> Even VNC could run fast enough for practical usage, I am confident that FB 
> is faster.
>   - Overlapping mode.
> It is possible that I implement overlapping mode on current Win-VNC client, 
> but if you do so, it is better to make a coLinux FB. Because, the biggest 
> merit of VNC is that there is a running code. If we need additional big 
> hack, VNC is not a good choice.
>   - FB code can be shared with UML.
> One of UML drawbacks is it does not have FB function. And I think coLinux FB 
> can be shared with UML. Rather just being shared, I proposed Lucas that we 
> should start a development from UML. I mean, first, we implement very easy 
> version of FB on UML, then port it to coLinux. The reason I propose such a 
> detoured way is, debugging function of UML is much better than coLinux.
> 
> FB is a perfect solution?:
> Of course, not. At least, FB has one drawback. FB does not support a cut and 
> paste while VNC does. Any solution?
> 
> Other issue:
> SDL has sound/mouse support. So probably sound/mouse ( coSound/coMouse?) 
> would be added to coLinux as a "coProduct" of a coFB driver.
> 
> 
> And Lucas, FYI, making shared memory buffer between coLinux and Host Windows 
> is easy. Any size is possible. The only restriction comparing to usual 
> shared buffer between WIn32 processes is, the memory must be "physical" one. 
> No virtual memory can be shared. I will do it if you afraid of it. I am not 
> sure that a format of Direct/X FB and Linux FB, (and SDL FB.. so on ), but 
> if they are same, same pages can be shared.
> 
>                                 --- Okajima.
> 
> 
> 
>>Hi,
>>
>>I will try to make a summary of what we have discussed so far (not much, 
>>to tell the truth) and other ideas I got in the meantime.
>>
>>First of all I have to say I'm no Linux developer, so much of my ideas 
>>may be wrong. I am still learning how the Linux kernel (and coLinux 
>>works). I just like this project very much and trying to contribute to it.
>>
>>The points are in no relevant order, just the order they come in my head.
>>
>>
>>1) FB or no FB ?
>>
>>There are obvious advantages on using the FB approach on this, but there 
>>may be other reasons to not use FB at all.
>>As the FLTK console seems to be doing ok, maybe an approach like a 
>>special modified XVnc server would work better (meaning easier to 
>>develop and with the same performance/results).
>>
>>2) Large blocks of memory shared between windows and colinux
>>
>>I was reading the IRC logs and da-x (Dan Aloni?) says he already has 
>>shared 64KB io buffer. I don't understand very well what that means, but 
>>seems we can now expect to share at least some memory between the host 
>>and the client OS. He also said something about some functions for 
>>mapping video memory into the windows kernel.
>>The problem here is that of massive memory transferences between colinux 
>>and windows (eg. playing a movie with mplayer fullscreen).
>>
>>3) The big question: Is it worthy?
>>
>>This question may seem dumb, but we are talking about this issue mostly 
>>because the network performance is weak. When the network performance 
>>improves to be the same as reading from a hardisk (it seems a goal 
>>perfectly reachable), meaning 10-50MB/s, then it could be there are 
>>other urgent things to improve than this. No 3D games, but no first 
>>prototype would give this, anyway.
>>
>>4) Implementation ideas:
>>
>>4.a) Using alpha channel to multi-window/rootless X server
>>
>>The idea from Okajima was that we could use the alpha channel in a 
>>clever way, so if the background used a special alpha color, no root 
>>window would appear (I'm taking this from memory, can be wrong).
>>
>>4.b) Use SDL on the windows and linux side
>>
>>SDL has a great advantage that it can use DirectX acceleration if 
>>available. An idea was to develop a coSDL library on the colinux side, 
>>that would communicate to the coSDL client on the windows side.
>>This could also be used when hosting colinux inside linux and even with 
> 
> UML.
> 
>>This could mean using a XSDL server (a la XVnc).
>>FB would be impractical because it requires a kernel module (at least 
>>it's my understanding). I believe a FB SDL driver can't be user mode.
>>
>>4.c) Implement a kernel device for inter-OS communication.
>>
>>A block device for inter-OS communication could be very useful for this 
>>and other projects (like a coSound driver). This is an idea I have, but 
>>as I'm still learning may or may not be the best.
>>The idea is developing a device that could be memory mapped, with some 
>>ioctl's for basic synchronization (at least a mutex on the device).
>>
>>
>>This is getting long, so I will stop here.
>>
>>Regards,
>>~Nuno Lucas
>>