From: Digital I. Inc. <ok...@di...> - 2004-07-07 13:56:52
|
Hello Folks. for a few months, I had looked into which way is better for coLinux graphics. and I got a temporary conclusion. It is that Frame buffer (FB) is one hopeful candidate. the biggest problem I think is, FB can not support overlapping (multi window) mode. if you dont understand what this is, please google with "cygwin/x multiwindow". and here is a solution I propose. 1. use 24bit color mode for Linux FB. I guess that probably this mode has below structure for each pixel. |not used 8Bit|R 8bit|G 8Bit|B 8Bit|. and the top 8 bit can be used for other purpose - for example, alpha (transparency) channel or Z ( depth in 3D) buffer. 2. assumes X server writes pixels with alpha = 0x00 ( for example.) if this assumption breaks, my proposal does not work. 3. making special "wall paper" util. this util does nothing, but fills the pixels with alpha = 0x01. ( any value is ok, except 0x00). --- so far, preparation ends. 4. bitblts the FB by this way: switch( pixel.alpha ) { case 0x00: bitblt( pixel, NO_TRANSPARENCY ); case 0x01: do_nothing(); // do not use alpha == 1 for alpha blending. default: bitblt( pixel, pixel.aplha - 1 ); } I dont know how to accelerate this way with DirectX bitblt, but I guess it is possible. and probably you already understood it, but if you make a special app which fill pixels with alpha > 1, you can make a transparent window. this way has one drawback -- many bitblts. but I estimate it not so big, hopefully. my estimation is, with PIII 1GHz with on board VGA, it is 10% or 20% degradation. and this drawback makes one good point. it uses DirectX to bitblt, so you can add some special effects though it. for example, waving or twisting a screen. even you can put a crystal cube on the Windows screen and map the FB as a texture. it resembles Longhorn. very good for marketing. and another ( and practical) stuff I would add is, new versatile overlapping modes. first , see this. http://www.digitalinfra.co.jp/overlapping.png if you map a FB as a wallpaper of Windows, your coLinux screen comes under Windows windows (funny English!). if you map it on the top of Windows screen with chroma-key effect I described above, this is probably what you want in the most cases. How about this idea? any suggestions, opinions are very welcome. --- Okajima. |
From: Nuno L. <nun...@zm...> - 2004-07-07 19:46:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Digital Infra, Inc., dando pulos de alegria, escreveu : | How about this idea? | any suggestions, opinions are very welcome. | | | --- Okajima. I never used any of this, but for those interested in more ideas, I noticed since Win2000 there is more low level API support for power developpers, without using DirectX. I'm talking of Raw Input [1] and Graphics Low Level Client Support [2]. This are just ideas for those interested in low level programming in windows. Direct X calls this API, so it could be nice to bypass all COM handling of Direct X and use the low level API instead. The downside is that it requires at least Win2000, but I don't see any problems in CoLinux requiring at least Win2000 to use the FrameBuffer. [1] Raw Input - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/rawinput.asp [2] Graphics Low Level Client Support - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/lowlevelclientsupport/dxlowlevelclientsupport.asp Regards, ~Nuno Lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA7FJz24S9OitwspoRAu/FAKCwqFwt89sSNYlQqKV5bdungkW3ugCgptPg 9yNctCpEG0KLXnFeCW3Kyv8= =EaH1 -----END PGP SIGNATURE----- |
From: Digital I. Inc. <ok...@di...> - 2004-07-07 23:32:44
|
Thanks, Lucas. It can reduce an overhead. and what you think about my "overlapping" way? this is the key point whether I decide a FB or not. I believe that overlapping ( multi window ) is necessary. --- Okajima. >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Digital Infra, Inc., dando pulos de alegria, escreveu : >| How about this idea? >| any suggestions, opinions are very welcome. >| >| >| --- Okajima. > >I never used any of this, but for those interested in more ideas, I >noticed since Win2000 there is more low level API support for power >developpers, without using DirectX. > >I'm talking of Raw Input [1] and Graphics Low Level Client Support [2]. > >This are just ideas for those interested in low level programming in >windows. Direct X calls this API, so it could be nice to bypass all COM >handling of Direct X and use the low level API instead. > >The downside is that it requires at least Win2000, but I don't see any >problems in CoLinux requiring at least Win2000 to use the FrameBuffer. > >[1] Raw Input - >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/rawinput.asp >[2] Graphics Low Level Client Support - >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/lowlevelclientsupport/dxlowlevelclientsupport.asp > >Regards, >~Nuno Lucas > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFA7FJz24S9OitwspoRAu/FAKCwqFwt89sSNYlQqKV5bdungkW3ugCgptP g >9yNctCpEG0KLXnFeCW3Kyv8= >=EaH1 >-----END PGP SIGNATURE----- > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Hen...@ar...> - 2004-07-22 08:25:12
|
Hello! Is a FB for coLinux in work? Or is this only a discussion for future? I am using SDL graphic under linux. This can also run under windows (special compiled). If SDL compiled for Windows, it give the software the actual bitblt engine for current Windows-Graphic hardware. And my user-program can directly manipulate every graphic bits in Windows Child Area. (I think "normal opened Window with white Client Area is, what you means with overlaping Windows? And a lot of them.) So I think: A new Graphic Daemon (under Windows) tells Linux only some Parameters about Windows Client Area. In fact, the Start-Address of Child Window Memory, Bytes per Line, Bytes per Bit and the Bit packing mode. Under Linux, the FB support use this hardware parameters and write diretly the pixel as a byte to memory. Many of bitblt functions are ready to use in linux kernel for a simple generic FB without accelerators. The Performance should be ok. My running SDL-Application in Windows have the same performace as under real linux. I am using only vesa FB in my linux notebook. No other video driver can't run on my hardware. Henry PS: Sorry for some mistaken words in english, it's not my default language. In private mail I am writing german. Digital Infra, Inc. wrote: > Hello Folks. > > for a few months, I had looked into which way is better for coLinux > graphics. and I got a temporary conclusion. It is that Frame buffer (FB) > is one hopeful candidate. > > the biggest problem I think is, FB can not support overlapping (multi > window) mode. if you dont understand what this is, > please google with "cygwin/x multiwindow". > > and here is a solution I propose. > > 1. use 24bit color mode for Linux FB. > I guess that probably this mode has below structure for each pixel. > |not used 8Bit|R 8bit|G 8Bit|B 8Bit|. > and the top 8 bit can be used for other purpose - for example, > alpha (transparency) channel or Z ( depth in 3D) buffer. > > 2. assumes X server writes pixels with alpha = 0x00 ( for example.) > if this assumption breaks, my proposal does not work. > > 3. making special "wall paper" util. > this util does nothing, but fills the pixels with alpha = 0x01. > ( any value is ok, except 0x00). > > --- so far, preparation ends. > > 4. bitblts the FB by this way: > switch( pixel.alpha ) > { > case 0x00: bitblt( pixel, NO_TRANSPARENCY ); > case 0x01: do_nothing(); > // do not use alpha == 1 for alpha blending. > default: bitblt( pixel, pixel.aplha - 1 ); > } > I dont know how to accelerate this way with DirectX bitblt, > but I guess it is possible. > and probably you already understood it, but if you make a special app > which fill pixels with alpha > 1, you can make a transparent window. > > this way has one drawback -- many bitblts. but I estimate it not so big, > hopefully. my estimation is, with PIII 1GHz with on board VGA, it is 10% > or 20% degradation. > and this drawback makes one good point. it uses DirectX to bitblt, so you > can add some special effects though it. for example, waving or twisting a > screen. even you can put a crystal cube on the Windows screen and map the > FB as a texture. it resembles Longhorn. very good for marketing. > > and another ( and practical) stuff I would add is, new versatile > overlapping modes. first , see this. > http://www.digitalinfra.co.jp/overlapping.png > if you map a FB as a wallpaper of Windows, your coLinux screen comes > under Windows windows (funny English!). if you map it on the top of > Windows screen with chroma-key effect I described above, this is probably > what you want in the most cases. > > How about this idea? > any suggestions, opinions are very welcome. > > > --- Okajima. > > |
From: Digital I. Inc. <ok...@di...> - 2004-07-22 13:34:18
|
Hello Nestler. > >Is a FB for coLinux in work? >Or is this only a discussion for future? > Currently, it still has been just a discussion between me and Lucas. >I am using SDL graphic under linux. This can also run under windows >(special compiled). If SDL compiled for Windows, it give the software >the actual bitblt engine for current Windows-Graphic hardware. And my >user-program can directly manipulate every graphic bits in Windows Child >Area. (I think "normal opened Window with white Client Area is, what you >means with overlaping Windows? And a lot of them.) > Well, Please google with "cygwin/x multiwindow". >So I think: A new Graphic Daemon (under Windows) tells Linux only some >Parameters about Windows Client Area. In fact, the Start-Address of >Child Window Memory, Bytes per Line, Bytes per Bit and the Bit packing mode. > >Under Linux, the FB support use this hardware parameters and write >diretly the pixel as a byte to memory. Many of bitblt functions are >ready to use in linux kernel for a simple generic FB without accelerators. > This is same issue about what I posted to Aloni. To utilize H/W acceleration, I think the only way is using Direct/X or Ian Pratt's technology which I have not understane well yet. >The Performance should be ok. My running SDL-Application in Windows have >the same performace as under real linux. I am using only vesa FB in my >linux notebook. No other video driver can't run on my hardware. > Which performance you mean? A full screen mode? or windowed mode? (Is right term?). I think SDL Win32 would slow when you use a "windowed mode". >Henry > >PS: Sorry for some mistaken words in english, it's not my default >language. In private mail I am writing german. > UMAI EIGO DAYO. ( "your english is not so bad" in Japanese). You are much better than me. --- Okajima. > >Digital Infra, Inc. wrote: > >> Hello Folks. >> >> for a few months, I had looked into which way is better for coLinux >> graphics. and I got a temporary conclusion. It is that Frame buffer (FB) >> is one hopeful candidate. >> >> the biggest problem I think is, FB can not support overlapping (multi >> window) mode. if you dont understand what this is, >> please google with "cygwin/x multiwindow". >> >> and here is a solution I propose. >> >> 1. use 24bit color mode for Linux FB. >> I guess that probably this mode has below structure for each pixel. >> |not used 8Bit|R 8bit|G 8Bit|B 8Bit|. >> and the top 8 bit can be used for other purpose - for example, >> alpha (transparency) channel or Z ( depth in 3D) buffer. >> >> 2. assumes X server writes pixels with alpha = 0x00 ( for example.) >> if this assumption breaks, my proposal does not work. >> >> 3. making special "wall paper" util. >> this util does nothing, but fills the pixels with alpha = 0x01. >> ( any value is ok, except 0x00). >> >> --- so far, preparation ends. >> >> 4. bitblts the FB by this way: >> switch( pixel.alpha ) >> { >> case 0x00: bitblt( pixel, NO_TRANSPARENCY ); >> case 0x01: do_nothing(); >> // do not use alpha == 1 for alpha blending. >> default: bitblt( pixel, pixel.aplha - 1 ); >> } >> I dont know how to accelerate this way with DirectX bitblt, >> but I guess it is possible. >> and probably you already understood it, but if you make a special app >> which fill pixels with alpha > 1, you can make a transparent window. >> >> this way has one drawback -- many bitblts. but I estimate it not so big, >> hopefully. my estimation is, with PIII 1GHz with on board VGA, it is 10% >> or 20% degradation. >> and this drawback makes one good point. it uses DirectX to bitblt, so you >> can add some special effects though it. for example, waving or twisting a >> screen. even you can put a crystal cube on the Windows screen and map the >> FB as a texture. it resembles Longhorn. very good for marketing. >> >> and another ( and practical) stuff I would add is, new versatile >> overlapping modes. first , see this. >> http://www.digitalinfra.co.jp/overlapping.png >> if you map a FB as a wallpaper of Windows, your coLinux screen comes >> under Windows windows (funny English!). if you map it on the top of >> Windows screen with chroma-key effect I described above, this is probably >> what you want in the most cases. >> >> How about this idea? >> any suggestions, opinions are very welcome. >> >> >> --- Okajima. >> >> > |
From: Henry N. <Hen...@ar...> - 2004-07-22 18:04:02
|
Hello Okajima, Digital Infra, Inc. wrote: > Hello Nestler. My first name is Henry ;-) >>Is a FB for coLinux in work? >>Or is this only a discussion for future? >> > > Currently, it still has been just a discussion between me and Lucas. ... and me :-) >>I am using SDL graphic under linux. This can also run under windows >>(special compiled). If SDL compiled for Windows, it give the software >>the actual bitblt engine for current Windows-Graphic hardware. And my >>user-program can directly manipulate every graphic bits in Windows Child >>Area. (I think "normal opened Window with white Client Area is, what you >>means with overlaping Windows? And a lot of them.) >> > > > Well, Please google with "cygwin/x multiwindow". Word "Multiwindows" I understand. I think, you will run a real linux window manager. So you need a completly single main-area, and in this area you can opverlap some linux pograms. But you can not move a program outside from the initial main-Window. You can not overlab such case: Win32 - Linux Win32 - Linux. Is this your discussion? >>So I think: A new Graphic Daemon (under Windows) tells Linux only some >>Parameters about Windows Client Area. In fact, the Start-Address of >>Child Window Memory, Bytes per Line, Bytes per Bit and the Bit packing mode. >> >>Under Linux, the FB support use this hardware parameters and write >>diretly the pixel as a byte to memory. Many of bitblt functions are >>ready to use in linux kernel for a simple generic FB without accelerators. >> > > > This is same issue about what I posted to Aloni. To utilize H/W acceleration, > I think the only way is using Direct/X or Ian Pratt's technology which I have > not understane well yet. Yes, DirectX is a very good API. But before you can implement DirectX, you need also a unaccelorated FB. The funktions for DirectX are only an acceloration for something, such moving/clearing a reactangle and so. >>The Performance should be ok. My running SDL-Application in Windows have >>the same performace as under real linux. I am using only vesa FB in my >>linux notebook. No other video driver can't run on my hardware. >> > > > Which performance you mean? A full screen mode? or windowed mode? (Is right term?). > I think SDL Win32 would slow when you use a "windowed mode". In real Linux I have no H/W acceleration. (No driver avalable) On the same machine: An SDL/Win32 program in an overlapping Window works with same speed, as the same program on FB under Linux. Yes, a full screen mode is a little bit faster. In both, Linux and SDL/Win32. I wrote a FB for a LCD long time ago. I know something about simple nonaccelorated FB. If a program put a pixel, the program have indirectly a direct access to memory address of video RAM. So it is normal, that the speed is the same. In other words: A fictive xserver running on colinux read the virtual_hardware_start_address, the bytes_per_line and byte_ofset-to_next_line from virtual window only at start. In running mode the xserver writes diretly the bits for colour of the pixel. Now, ok. This type of FB is not very good for high speed running games. KDE will be load for a while. I am using icewm. Henry |
From: Nuno L. <nt...@nl...> - 2004-07-22 20:00:52
|
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 |
From: Tim L. <ti...@ke...> - 2004-07-22 20:19:35
|
On Thu, Jul 22, 2004 at 08:50:07PM +0100, Nuno Lucas wrote: > 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. <snip/> ...And to add one more, XGGI implemented via writing a colinux target for the linux port of the GGI library and a small Windows app using GGI's DirectX target, communicating via direct buffers (shared memory) and using coserial to batch commands across the colinux<->windows barrier. This approach would even allow for graphics accelleration. http://sourceforge.net/projects/ggi/ http://www.ggi-project.org/ --Tim Larson |
From: Digital I. Inc. <ok...@di...> - 2004-07-23 07:27:35
|
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 > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Hen...@ar...> - 2004-07-23 18:50:04
|
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 >> |
From: Digital I. Inc. <ok...@di...> - 2004-07-24 16:00:23
|
Hello Henry ( is right?). Well, I suppose you get one mistake. coLinux FB can not write directly to VRAM if a client window is "windowed", not a full screen mode. And even if it is a full screen mode, you should not write VRAM directly. Generally, wrinting VRAM is slow. Generally, it is better to write a fb once, and then memcpy to VRAM. Check an implementation of some games. And I think we can use some feature of Direct/X H/W acceraletion for even copying fb -> VRAM. Although I am not sure about it. And of course, UML is User Mode Linux. You can inspect a running virtual kernel with GDB. For a solution of supporting copy-and-paste ( probably this is more common term.), one idea is using KDE/Gnome's own build-in feature. --- Okajima. >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 >>> > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Nuno L. <nt...@nl...> - 2004-07-24 17:59:45
|
Digital Infra, Inc., dando pulos de alegria, escreveu : <snip> > And I think we can use some feature of Direct/X H/W acceraletion for even > copying fb -> VRAM. Although I am not sure about it. I believe SDL/GGI can take care of this, if available (at least that's what the documentation says). > For a solution of supporting copy-and-paste ( probably this is more common > term.), one idea is using KDE/Gnome's own build-in feature. This can also be made by a user program that simply synchronizes copy/paste operations with another user program in the host OS, using sockets. Slower, but effective nevertheless. ---- In another subject, maybe GGI is better for the job. It abstracts X, DirectFB and SVGA targets, so one doesn't need to be aware of what the current mode is. The problem here is only on Linux as the host OS. GGI abstracts all this and use the best graphics mode available. A good intro on GGI is here: http://www.ggi-project.org/documentation/topic-brian-fsm.html Thanks to Tim Larson for indicating GGI. It sure seems the future!!! > --- Okajima. Regards, ~Nuno Lucas |
From: Nuno L. <nt...@nl...> - 2004-07-24 19:10:20
|
Nuno Lucas, dando pulos de alegria, escreveu : > In another subject, maybe GGI is better for the job. It abstracts X, > DirectFB and SVGA targets, so one doesn't need to be aware of what the > current mode is. Oops, I have to reconsider this. Windows port was only made on the current version. I don't think it's stable enough, at least after some browsing in the mail archives. I'm trying to compile it on cygwin, but I'm still trying :( Regards, ~Nuno Lucas |
From: Tim L. <ti...@ke...> - 2004-07-26 03:49:22
|
On Sat, Jul 24, 2004 at 08:10:11PM +0100, Nuno Lucas wrote: > Nuno Lucas, dando pulos de alegria, escreveu : > >In another subject, maybe GGI is better for the job. It abstracts X, > >DirectFB and SVGA targets, so one doesn't need to be aware of what the > >current mode is. > > Oops, I have to reconsider this. Windows port was only made on the > current version. I don't think it's stable enough, at least after some > browsing in the mail archives. > > I'm trying to compile it on cygwin, but I'm still trying :( In case you are still interested, the GGI developers mostly hang out on the #ggi IRC channel on the freenode network, log at http://woo.li/logs/ This is where I would recommend to go if you need any help with the library, as the IRC channel is much more active than the mailing list, and they usually read the backog and answer questions even if you ask when they are not logged on (just remember to indicate that you will watch the IRC log for their comments). HTH, --Tim Larson |
From: Tim L. <ti...@ke...> - 2004-07-26 13:43:21
|
On Sat, Jul 24, 2004 at 08:10:11PM +0100, Nuno Lucas wrote: > Nuno Lucas, dando pulos de alegria, escreveu : > >In another subject, maybe GGI is better for the job. It abstracts X, > >DirectFB and SVGA targets, so one doesn't need to be aware of what the > >current mode is. > > Oops, I have to reconsider this. Windows port was only made on the > current version. I don't think it's stable enough, at least after some > browsing in the mail archives. > > I'm trying to compile it on cygwin, but I'm still trying :( I asked on the ggi irc channel and they said to compile with mingw instead of with cygwin. Building with cygwin is not currently supported. --Tim Larson |
From: Nuno L. <nt...@nl...> - 2004-07-26 14:08:15
|
Tim Larson, dando pulos de alegria, escreveu : >>I'm trying to compile it on cygwin, but I'm still trying :( > > I asked on the ggi irc channel and they said to compile with mingw > instead of with cygwin. Building with cygwin is not currently > supported. Thanks. I don't have mingw installed right now, but at least now I know what I should be doing. In the meantime, I still think that we shouldn't use GGI for this, because using experimental code to develop experimental code is not my idea of a good start. But the code should be generic enough to let us switch the engine at will, so it remains a good candidate for the future (at least I was impressed with the GGI philosophy). Regards, ~Nuno Lucas |
From: Nuno L. <nt...@nl...> - 2004-07-24 16:14:33
|
Digital Infra, Inc., dando pulos de alegria, escreveu : > First, Lucas, Thank you for good summary. > ( I am not sure which to use --- Nuno or Lucas.) Either one is ok, or both (I have 4 more names you can choose also ;) <snip> > 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. The current snapshot already provides a coMouse driver, but I don't know if it is working. > 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. 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. > 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 a time. > > --- Okajima. Regards, ~Nuno Lucas |
From: Digital I. Inc. <ok...@di...> - 2004-07-25 03:02:35
|
>> 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. > >> 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. > >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. >> 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 >a time. > 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? --- Okajima. |
From: Nuno L. <nt...@nl...> - 2004-07-25 06:02:51
|
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 prototype. >>>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. >> >>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 >>a time. > > 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. Regards, ~Nuno Lucas |
From: Digital I. Inc. <ok...@di...> - 2004-07-25 09:36:33
|
Copy/Paste: > >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 >prototype. > Okay, we agreed most part, leaving just an actual implement. I hope you can make a good prototype. If it is good, lets go with it. Sound: > >Yes, seems reasonable to me. > Okay, we agreed this point also. But this does not mean we had looked into all possiblities. I hope anybody gives us any objection. > >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 ;). > Umm... Thinking a little... I guess, it means "Buying a big house before you get married". ( <- Okajima original saying.) >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), No. you dont need doubel buffering, unless you write VRAM directly. Redering to a fb -> Bitbltting to VRAM -> Rendering .... This loop does not need a double buffering method. And I dont think writing VRAM directly is good idea. Even you write directly, you still dont need a double fb. In this case, you need a double VRAM, not double fb. Showing a VRAM 1, Rendering to a VRAM 2 -> Flipping by changing a video chip registor -> Showing a VRAM 2, Rendering to a VRAM 1 -> Flipping ... >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. > You care about H/W dependency of FB? No problem. SDL Win32 and Direct/X will handle all compatibility issue. >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. > Of course, you dont allocate a FB memory statically. You can do something like char *FB.buf = coLinux_phy_alloc( FB_SIZE ); >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. > Yes. I believe that the first milestone should be very easy one. But we must have a long term plan also. --- Okajima. |
From: Nuno L. <nt...@nl...> - 2004-07-26 14:50:16
|
Digital Infra, Inc., dando pulos de alegria, escreveu : > Copy/Paste: Answered on the new thread you started... > Sound: > > Okay, we agreed this point also. > But this does not mean we had looked into all possiblities. > I hope anybody gives us any objection. Yep, it's hard to talk on something I don't have much knowledge. Just for the record, one other library (besides SDL) that is ok for this is FMod (www.fmod.org). It's a professional looking library, used by many good commercial games (including FarCry, the recent top rated RPG game). It's ok to use in Open Source programs (needs a license for commercial applications). >>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 ;). > > Umm... Thinking a little... I guess, it means > "Buying a big house before you get married". ( <- Okajima original saying.) Yes, this seems a good approximation, hehe. > No. you dont need doubel buffering, unless you write VRAM directly. > Redering to a fb -> Bitbltting to VRAM -> Rendering .... > This loop does not need a double buffering method. > And I dont think writing VRAM directly is good idea. > Even you write directly, you still dont need a double fb. > In this case, you need a double VRAM, not double fb. > Showing a VRAM 1, Rendering to a VRAM 2 -> Flipping by changing a video chip registor > -> Showing a VRAM 2, Rendering to a VRAM 1 -> Flipping ... Ok, I was thinking in terms of the SDL function for SDL_SetVideoMode(w, h, bpp, flags), where flags could be (SDL_HWSURFACE | SDL_DBLBUFFER). It would create a surface on the video memory and SDL_Flip would make the update. From what I understood, it would have success even if no video memory available and SDL_Flip would became a SDL_UpdateRects on the entire screen. Anyway, this is an implementation detail. >>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. > > You care about H/W dependency of FB? No problem. > SDL Win32 and Direct/X will handle all compatibility issue. That was my idea, as I wrote above. >>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. > > Of course, you dont allocate a FB memory statically. > You can do something like > char *FB.buf = coLinux_phy_alloc( FB_SIZE ); As I don't have any idea on how to allocate this shared memory, I was just saying it should be allocated only on first use, not on the kernel boot. And, if possible, released when no longer needed (by detaching the screen). I don't know how Dan Aloni makes this on the console code. If it does the same thing, probably it's just a matter of copying the code. But I had the impression, from browsing the code, it uses no shared memory for this, just message passing (off course he needs shared memory for the message passing mechanism). >>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. > > Yes. I believe that the first milestone should be very easy one. > But we must have a long term plan also. We all agree on this :) > --- Okajima. Regards, ~Nuno Lucas P.S.- I am talking of Dan Aloni mostly because I only know him as the lead developer, but I'm sure I should be crediting others as well. Just want to take this opportunity to thank all others involved that I don't know of. Kudos to all! :) |
From: Henry N. <Hen...@ar...> - 2004-07-28 09:10:28
|
Nuno Lucas wrote: > Digital Infra, Inc., dando pulos de alegria, escreveu : > [...] > >> No. you dont need doubel buffering, unless you write VRAM directly. >> Redering to a fb -> Bitbltting to VRAM -> Rendering .... >> This loop does not need a double buffering method. >> And I dont think writing VRAM directly is good idea. >> Even you write directly, you still dont need a double fb. >> In this case, you need a double VRAM, not double fb. >> Showing a VRAM 1, Rendering to a VRAM 2 -> Flipping by changing a video chip registor >> -> Showing a VRAM 2, Rendering to a VRAM 1 -> Flipping ... > > Ok, I was thinking in terms of the SDL function for > SDL_SetVideoMode(w, h, bpp, flags), where flags could be > (SDL_HWSURFACE | SDL_DBLBUFFER). It would create a surface on > the video memory and SDL_Flip would make the update. That's absolutly correct. > From what I understood, it would have success even if no video > memory available and SDL_Flip would became a SDL_UpdateRects on > the entire screen. > Anyway, this is an implementation detail. Double-Buffer need a SDL_Flip. The application (our FB driver) must inform about double buffering. Application should repaint the completly Screen. In other case we have two half frames with different contens. SDL_UpdateRect was call under SDL, to copy data from no viewing RAM into hardware VRAM. It is designed for slow video hardware. So you can rendering very fast into virtual memory. If Rendering ready, SDL puts your data to hardware. It is very fast, because SDL minimised the count of access to VRAM. VRAM (in video card) is slower than SDRAM (on main oard). VRAM ist not cached, SDRAM is cached on CPU. My question: Have FB driver a signal to trigger the Update or Flip? I think no. Henry |
From: Digital I. Inc. <ok...@di...> - 2004-07-28 14:44:03
|
Hello Henry. Well, I am not sure about SDL stuff, but what you said seems to be that SDL needs just a one frame buffer. I mean, there is one FB and one VRAM. and you transfer FB -> VRAM with SDL_Flip(); Am I getting something wrong? Note: A frame buffer I mentioned here is, it means a heap allocated by malloc() or something like that. Not a RAM on your video card. --- Okajima. >Nuno Lucas wrote: > >> Digital Infra, Inc., dando pulos de alegria, escreveu : >> >[...] > >> >>> No. you dont need doubel buffering, unless you write VRAM directly. >>> Redering to a fb -> Bitbltting to VRAM -> Rendering .... >>> This loop does not need a double buffering method. >>> And I dont think writing VRAM directly is good idea. >>> Even you write directly, you still dont need a double fb. >>> In this case, you need a double VRAM, not double fb. >>> Showing a VRAM 1, Rendering to a VRAM 2 -> Flipping by changing a video chip registor >>> -> Showing a VRAM 2, Rendering to a VRAM 1 -> Flipping ... >> >> Ok, I was thinking in terms of the SDL function for >> SDL_SetVideoMode(w, h, bpp, flags), where flags could be >> (SDL_HWSURFACE | SDL_DBLBUFFER). It would create a surface on >> the video memory and SDL_Flip would make the update. > >That's absolutly correct. > >> From what I understood, it would have success even if no video >> memory available and SDL_Flip would became a SDL_UpdateRects on >> the entire screen. >> Anyway, this is an implementation detail. > > >Double-Buffer need a SDL_Flip. >The application (our FB driver) must inform about double buffering. >Application should repaint the completly Screen. >In other case we have two half frames with different contens. > >SDL_UpdateRect was call under SDL, to copy data from no viewing RAM >into hardware VRAM. It is designed for slow video hardware. So you can >rendering very fast into virtual memory. If Rendering ready, SDL puts >your data to hardware. It is very fast, because SDL minimised the count >of access to VRAM. VRAM (in video card) is slower than SDRAM (on main >oard). VRAM ist not cached, SDRAM is cached on CPU. > >My question: >Have FB driver a signal to trigger the Update or Flip? I think no. > >Henry > > > > > > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Hen...@ar...> - 2004-07-29 08:38:42
|
Hello! Digital Infra, Inc. wrote: > Hello Henry. > > Well, I am not sure about SDL stuff, but what you said seems to > be that SDL needs just a one frame buffer. I mean, there is one > FB and one VRAM. and you transfer FB -> VRAM with SDL_Flip(); > Am I getting something wrong? > > Note: A frame buffer I mentioned here is, it means a heap allocated by > malloc() or something like that. Not a RAM on your video card. No, SDL_Flip set only start address for visable videoram from VRAM1 to VRAM2 and back. SDL work in this ways. Double buffering with direct hardware writing into unvisable VRAM and make it visable with SDL_Flip. The function SDL_UpdateRect is only "do nothing - return" for this mode. It works only at full screen. (see functions FB_FlipHWSurface and FB_DirectUpdate in SDL-1.2.3\src\video\fbcon\SDL_fbvideo.c) This mode is good for real view of any video frames (in a time). But it makes colinux slower. Here we can use a generic functions from real linux FB driver. Other way is, SDL give a virtual buffer (ala malloc) and the application do something in this virtual memory. The function SDL_UpdateRect move bits from virtual memory into VRAM of graphic card. Sometime the update function also convert from SDL colour mode into Real color mode. Oh no, under multi window Windows, the update function copy bytes only from one virtal memory (SDL) into other virtal memory (Window Client area). Here colinux works very quickly, because it works only in virtual memory. The update function is compair with the windows "Repaint event". So you can lose some video frames. The colinuxFB shold be handle both. Thist for Gamers and second for X-applications what need not fast screen updates, so colinuxFB can run in a window box. I can try to make a prototype for colinuxFB with SDL. I write a colinuxFB, and on other side I can build a SDL-application with "frame buffer". SDL allocate the virtual memory and must give the start addres and some oher things into colinux kernel, but not the memory self. All this compiled under Liunx for mingw32. I need some helps for colinux messaging between SDL-program and colinux Kernel! PS: I have ready compiled SDL demos for mingw32. They demonstrate the comparsion between Hardware-Flip and Update-Mode. testfb.c demonstrate the "write a pixel into framebuffer". http://home.arcor.de/henryn/sdl-demos-mingw32.zip Usage: testsprite.exe [-bpp N] [-hw] [-flip] [-fast] [-fullscreen] [numsprites] Henry > >> Nuno Lucas wrote: >> >> >>> Digital Infra, Inc., dando pulos de alegria, escreveu : >>> >> >> [...] >> >> >>>> No. you dont need doubel buffering, unless you write VRAM directly. >>>> Redering to a fb -> Bitbltting to VRAM -> Rendering .... >>>> This loop does not need a double buffering method. >>>> And I dont think writing VRAM directly is good idea. >>>> Even you write directly, you still dont need a double fb. >>>> In this case, you need a double VRAM, not double fb. >>>> Showing a VRAM 1, Rendering to a VRAM 2 -> Flipping by changing a video chip > > > registor > >>>> -> Showing a VRAM 2, Rendering to a VRAM 1 -> Flipping ... >>> >>> >>> Ok, I was thinking in terms of the SDL function for >>> SDL_SetVideoMode(w, h, bpp, flags), where flags could be >>> (SDL_HWSURFACE | SDL_DBLBUFFER). It would create a surface on >>> the video memory and SDL_Flip would make the update. >> >> >> That's absolutly correct. >> >> >>> From what I understood, it would have success even if no video memory available and SDL_Flip would became a SDL_UpdateRects on >>> the entire screen. >>> Anyway, this is an implementation detail. >> >> >> >> Double-Buffer need a SDL_Flip. >> The application (our FB driver) must inform about double buffering. >> Application should repaint the completly Screen. >> In other case we have two half frames with different contens. >> >> SDL_UpdateRect was call under SDL, to copy data from no viewing RAM >> into hardware VRAM. It is designed for slow video hardware. So you can >> rendering very fast into virtual memory. If Rendering ready, SDL puts >> your data to hardware. It is very fast, because SDL minimised the count >> of access to VRAM. VRAM (in video card) is slower than SDRAM (on main >> oard). VRAM ist not cached, SDRAM is cached on CPU. >> >> My question: >> Have FB driver a signal to trigger the Update or Flip? I think no. >> >> Henry >> > |
From: Digital I. Inc. <ok...@di...> - 2004-07-29 10:29:56
|
> > > > Well, I am not sure about SDL stuff, but what you said seems to > > be that SDL needs just a one frame buffer. I mean, there is one > > FB and one VRAM. and you transfer FB -> VRAM with SDL_Flip(); > > Am I getting something wrong? > > > > Note: A frame buffer I mentioned here is, it means a heap allocated by > > malloc() or something like that. Not a RAM on your video card. > >No, SDL_Flip set only start address for visable videoram from VRAM1 to >VRAM2 and back. > >SDL work in this ways. > Double buffering with direct hardware writing into unvisable VRAM and >make it visable with SDL_Flip. The function SDL_UpdateRect is only "do >nothing - return" for this mode. It works only at full screen. (see >functions FB_FlipHWSurface and FB_DirectUpdate in >SDL-1.2.3\src\video\fbcon\SDL_fbvideo.c) >This mode is good for real view of any video frames (in a time). But it >makes colinux slower. >Here we can use a generic functions from real linux FB driver. > > Other way is, SDL give a virtual buffer (ala malloc) and the >application do something in this virtual memory. The function >SDL_UpdateRect move bits from virtual memory into VRAM of graphic card. >Sometime the update function also convert from SDL colour mode into Real >color mode. >Oh no, under multi window Windows, the update function copy bytes only >from one virtal memory (SDL) into other virtal memory (Window Client area). >Here colinux works very quickly, because it works only in virtual >memory. The update function is compair with the windows "Repaint event". >So you can lose some video frames. > >The colinuxFB shold be handle both. Thist for Gamers and second for >X-applications what need not fast screen updates, so colinuxFB can run >in a window box. > Okay, First, we should check the terminology. Of course, coLinux is new criteria, so there is no authority to fix it. But I make temporarily one for convinience. ------------ Okajima's sloppy dictionary starts ----- Frame Buffer .... 1. coLinux graphic function. 2. a malloc()ed memory which holds a bit map of a screen. VRAM .... A semiconductor memory on a video card. Page .... 1. 4K bytes chunk of memory which has very ambiguos and sensitive meaning for coLinux. Who explains what is a "virtual physical page" means? (4K is if coLinux runs on x86.) 2. A memory which fits to holds a one screen. Bitblt .... memcpy() for bitmap stuff. Often it is acceraleted by H/W. Flipping .... 1. (extended meaning) changing a page. 2. (usual meaning of this thread) changing a page without bitblitting, but by changing H/W resistor. -------------------------------------------------------- With this terminology, the first one is, - double pages in a VRAM, and you flip it. No bitblt. In my terminology, this is not a frame buffer of meaning 2. And the second one is, - one page in a VRAM, one page in a FB, and you bitblt a fb -> a vram each time. This a "real" frame buffer of my terminology. >I can try to make a prototype for colinuxFB with SDL. >I write a colinuxFB, and on other side I can build a SDL-application >with "frame buffer". SDL allocate the virtual memory and must give the >start addres and some oher things into colinux kernel, but not the >memory self. All this compiled under Liunx for mingw32. >I need some helps for colinux messaging between SDL-program and colinux >Kernel! > >PS: I have ready compiled SDL demos for mingw32. They demonstrate the >comparsion between Hardware-Flip and Update-Mode. testfb.c demonstrate >the "write a pixel into framebuffer". >http://home.arcor.de/henryn/sdl-demos-mingw32.zip >Usage: testsprite.exe [-bpp N] [-hw] [-flip] [-fast] [-fullscreen] >[numsprites] > >Henry > > > > > >> Nuno Lucas wrote: > >> > >> > >>> Digital Infra, Inc., dando pulos de alegria, escreveu : > >>> > >> > >> [...] > >> > >> > >>>> No. you dont need doubel buffering, unless you write VRAM directly. > >>>> Redering to a fb -> Bitbltting to VRAM -> Rendering .... > >>>> This loop does not need a double buffering method. > >>>> And I dont think writing VRAM directly is good idea. > >>>> Even you write directly, you still dont need a double fb. > >>>> In this case, you need a double VRAM, not double fb. > >>>> Showing a VRAM 1, Rendering to a VRAM 2 -> Flipping by changing a >video chip > > > > > > registor > > > >>>> -> Showing a VRAM 2, Rendering to a VRAM 1 -> Flipping ... > >>> > >>> > >>> Ok, I was thinking in terms of the SDL function for > >>> SDL_SetVideoMode(w, h, bpp, flags), where flags could be > >>> (SDL_HWSURFACE | SDL_DBLBUFFER). It would create a surface on > >>> the video memory and SDL_Flip would make the update. > >> > >> > >> That's absolutly correct. > >> > >> > >>> From what I understood, it would have success even if no video >memory available and SDL_Flip would became a SDL_UpdateRects on > >>> the entire screen. > >>> Anyway, this is an implementation detail. > >> > >> > >> > >> Double-Buffer need a SDL_Flip. > >> The application (our FB driver) must inform about double buffering. > >> Application should repaint the completly Screen. > >> In other case we have two half frames with different contens. > >> > >> SDL_UpdateRect was call under SDL, to copy data from no viewing RAM > >> into hardware VRAM. It is designed for slow video hardware. So you can > >> rendering very fast into virtual memory. If Rendering ready, SDL puts > >> your data to hardware. It is very fast, because SDL minimised the count > >> of access to VRAM. VRAM (in video card) is slower than SDRAM (on main > >> oard). VRAM ist not cached, SDRAM is cached on CPU. > >> > >> My question: > >> Have FB driver a signal to trigger the Update or Flip? I think no. > >> > >> Henry > >> > > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |