Digital Infra, Inc., dando pulos de alegria, escreveu :
>>>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?
>>I don't think so. That should need to be addressed in the core FB
>>module, not on the driver level. I believe a solution could be hacking
>>the cut & paste mechanism in the X level, a la XWin way. I believe they
>>use a X extension to do this, but I didn't look into it.
> Yes, you are right. I discussed two different piece at once.
> But anyway, VNC comes with a cut and paste function.
> So if we dont use VNC, we have to look for some solution.
> As I wrote in another mail, I propose that using KDE/Gnome func.
> I am not sure which way is better. All guys, Your opinion is welcome.
As I said in another mail, I think we can achieve this by a typical
client/server program, only in user space. Maybe that should be enough
for a first prototype (with the advantage of working in all platforms).
A windows/linux server would wait for the host OS copy events and notify
his clients when that happen (and transfer the data on request).
Every client would do the same on the client OS side, but only talking
with the server.
I just run across a SDL copy/paste sample. I will try to make a working
>>>SDL has sound/mouse support. So probably sound/mouse ( coSound/coMouse?)
>>>would be added to coLinux as a "coProduct" of a coFB driver.
>>Yes, that was my idea too. I also thought it could be a good project to
>>test the coFB driver ideas. After all, the basic mechanism is the same,
>>but maybe it could prove to be a misleading idea (sound processing is
>>not so basic as one could think). I know there is a dummy sound driver
>>that could be a good starting point for this.
> First, we should define the goal. For my goal, it is just sounding.
> I mean, it is like "Musi .,,, c (noise) Star...t...ttt.".
> I suppose that the difficult part is how to assure QoS.
> And I dont care about QoS, so implementing a sound is easy.
> Someday, coLinux may become a poring library for Linux game.
> If so, sounding with QoS would be important.
> but I think it is not time to care about such future possiblity.
Yes, seems reasonable to me.
>>>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.
>>This needs to be thinked about. We could expect coLinux, like UML, to be
>>used to emulate a server farm. The design should take into account that
>>if no "colinux-fbdriver-daemon.exe" takes responsibility of a virtual
>>colinux screen, no memory should be allocated. That way we can have many
>>colinux virtual machines, but only wasting physical memory on the one
>>(or more?) we are actually viewing.
>>Also, we may want to simulate multiple screens, but only viewing one at
> Wait, Lucas. Probably you have a misunderstand.
> First, FB is not so big. Actually, today's video cards have much memory, e.g. 64MB.
> But, we need only 2MB or such for each screen.
> And your idea, emulating a server farm on Windows, is not wrong,
> but for that purpose, you dont need a fb for each VM.
> You make one VM with a fb, and others with just a console and X client.
> I think if only one VM has X server, it must be enough.
> Or why you need a fb for all VMs?
Probably I'm just putting the car in front of the horses (a popular
saying in my country, don't know if it applies in English ;).
Anyway, 1024x768x32 = 3MB, 1280x1024x32 = 5MB, ...
As this memory can't be used by any other program and I'm thinking in
double buffering (to avoid artifacts), and we don't know in which
hardware we will be running, it should be at least a goal for the
driver. In a prototype it wouldn't matter much, but I think the design
should take that into account.
In my idea, the FB driver could be statically compiled into the kernel
without problems, but memory would only be allocated on a screen attachment.
As I said, no problem in not implementing this right at start, but it
would be good to have that possibility open for the future.
> --- Okajima.