From: Henry N. <Hen...@ar...> - 2004-08-01 11:51:45
|
http://home.arcor.de/henryn/sdl_colinux-20040730.zip TESTFB5.EXE: Runs a SDL-Framebuffer-Daemon. This starts with a colour raster and wait than for update flag. SHM_TEST5.EXE: Run this will put many rectangles into shared memory. First quit some informations about shared memory with Enter key. After every rectangle this will set an update bit and update coordinates for rect (only one rect). TESTFB5F.EXE: The same, but ignor rect sizes. Always update full 640x480 area. Here you can verify the performance to TESTFB5.EXE. What do they programs? Are only a simple test, how can I do connect two programs via shared memory under Windows. The SDL-Daemon was compiled from linux with mingw. The SHM_TEST5.C simulate the update-rect from a kernel-FB-Driver in frame buffer memory. Yes, this is all not perfect, but it's my first windows program with shared memory. I have read some helps and do make up to test5. I have not understand all the "virtual", "paged" and so in mailing list. Yes, I know this from some kernel programmings. But in this sample I do not need this. After this sample I think, it's very easy to connect colinux kernel-daemon to a viewer for framebuffer. I am using SDL, because it's my homebase tool for graphics. Please show into my source. Yes, they are not complety perfect and not structured for work in real project. Many constans are hard coded, such video base of 640x480x256 (8 bit) in shared memory. It was compiled under linux SuSE 9.0 (in a colinux box!) and I run this on XP Home. My video settings in XP are 1024x768x32k (16 bit color deph). This sample should everybody help to understand framebuffer, and shared memory problems. It's the beginning for "coLinux graphics" without VNC & Co. Thanks for many ideas in the long ML-thread before! Nice effect: Run 2x TESTFB5.EXE and than SHM_TEST5.EXE ;-) Next? Anybody should be give some samples, how can use dirty bit of MMU! And a implementation of shared memory into colinux kernel. Henry |
From: Digital I. Inc. <ok...@di...> - 2004-08-01 17:54:07
|
Thanks, Henry. I ran it and actually it ran on my PC. Good. And for a dirty bit stuff, First, check this please. http://lxr.linux.no/ident?i=PG_dirty --- Okajima. >http://home.arcor.de/henryn/sdl_colinux-20040730.zip > >TESTFB5.EXE: > Runs a SDL-Framebuffer-Daemon. > This starts with a colour raster and > wait than for update flag. > >SHM_TEST5.EXE: > Run this will put many rectangles into shared memory. > First quit some informations about shared memory with Enter key. > After every rectangle this will set an update bit and update > coordinates for rect (only one rect). > >TESTFB5F.EXE: > The same, but ignor rect sizes. Always update full 640x480 area. > Here you can verify the performance to TESTFB5.EXE. > >What do they programs? > Are only a simple test, how can I do connect two programs via shared >memory under Windows. The SDL-Daemon was compiled from linux with mingw. > >The SHM_TEST5.C simulate the update-rect from a kernel-FB-Driver in >frame buffer memory. > >Yes, this is all not perfect, but it's my first windows program with >shared memory. I have read some helps and do make up to test5. I have >not understand all the "virtual", "paged" and so in mailing list. Yes, I >know this from some kernel programmings. But in this sample I do not >need this. After this sample I think, it's very easy to connect colinux >kernel-daemon to a viewer for framebuffer. >I am using SDL, because it's my homebase tool for graphics. > >Please show into my source. Yes, they are not complety perfect and not >structured for work in real project. Many constans are hard coded, such >video base of 640x480x256 (8 bit) in shared memory. > >It was compiled under linux SuSE 9.0 (in a colinux box!) and I run this >on XP Home. My video settings in XP are 1024x768x32k (16 bit color deph). > >This sample should everybody help to understand framebuffer, and shared >memory problems. It's the beginning for "coLinux graphics" without VNC & >Co. Thanks for many ideas in the long ML-thread before! > >Nice effect: Run 2x TESTFB5.EXE and than SHM_TEST5.EXE ;-) > >Next? >Anybody should be give some samples, how can use dirty bit of MMU! And a >implementation of shared memory into colinux kernel. > >Henry > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Hen...@ar...> - 2004-08-02 16:54:31
|
Thanks. But, how can I do this on Windows side? Have Windows also such bit for virtual memory? I will lock into win API again ...grrr... Henry Digital Infra, Inc. wrote: > Thanks, Henry. > > I ran it and actually it ran on my PC. Good. > And for a dirty bit stuff, First, check this please. > http://lxr.linux.no/ident?i=PG_dirty > > --- Okajima. > > > >>http://home.arcor.de/henryn/sdl_colinux-20040730.zip >> >>TESTFB5.EXE: >> Runs a SDL-Framebuffer-Daemon. >> This starts with a colour raster and >> wait than for update flag. >> >>SHM_TEST5.EXE: >> Run this will put many rectangles into shared memory. >> First quit some informations about shared memory with Enter key. >> After every rectangle this will set an update bit and update >> coordinates for rect (only one rect). >> >>TESTFB5F.EXE: >> The same, but ignor rect sizes. Always update full 640x480 area. >> Here you can verify the performance to TESTFB5.EXE. >> >>What do they programs? >> Are only a simple test, how can I do connect two programs via shared >>memory under Windows. The SDL-Daemon was compiled from linux with mingw. >> >>The SHM_TEST5.C simulate the update-rect from a kernel-FB-Driver in >>frame buffer memory. >> >>Yes, this is all not perfect, but it's my first windows program with >>shared memory. I have read some helps and do make up to test5. I have >>not understand all the "virtual", "paged" and so in mailing list. Yes, I >>know this from some kernel programmings. But in this sample I do not >>need this. After this sample I think, it's very easy to connect colinux >>kernel-daemon to a viewer for framebuffer. >>I am using SDL, because it's my homebase tool for graphics. >> >>Please show into my source. Yes, they are not complety perfect and not >>structured for work in real project. Many constans are hard coded, such >>video base of 640x480x256 (8 bit) in shared memory. >> >>It was compiled under linux SuSE 9.0 (in a colinux box!) and I run this >>on XP Home. My video settings in XP are 1024x768x32k (16 bit color deph). >> >>This sample should everybody help to understand framebuffer, and shared >>memory problems. It's the beginning for "coLinux graphics" without VNC & >>Co. Thanks for many ideas in the long ML-thread before! >> >>Nice effect: Run 2x TESTFB5.EXE and than SHM_TEST5.EXE ;-) >> >>Next? >>Anybody should be give some samples, how can use dirty bit of MMU! And a >>implementation of shared memory into colinux kernel. >> >>Henry >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by OSTG. Have you noticed the changes on >>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >>one more big change to announce. We are now OSTG- Open Source Technology >>Group. Come see the changes on the new OSTG site. www.ostg.com >>_______________________________________________ >>coLinux-devel mailing list >>coL...@li... >>https://lists.sourceforge.net/lists/listinfo/colinux-devel >> > > |
From: Digital I. Inc. <ok...@di...> - 2004-08-10 15:51:17
|
Hello Henry. Sorry for a late reply. I can not tell you immediately how to use this bit from Windows, without searching on MSDN/DDK or such. But one thing you seem to miss --- this is not OS function, but CPU function. I dont think MS prohibits to use this function. Anyway, check here: http://www.intel.com/design/pentium4/documentation.htm http://www.intel.com/design/pentium4/manuals/index_new.htm http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html And you have "Inside NT" the definitive book of Germen edition? If not, rush to the amazon.com now. This book gives you very detailed stuff about how NT handles a dirty bit. And other issues relate to coLinux are also described well. For example, you know what "MDL" means as NT term? http://www.amazon.com/exec/obidos/search-handle-form/102-8250566-4536165 --- Okajima. >Thanks. But, how can I do this on Windows side? Have Windows also such >bit for virtual memory? >I will lock into win API again ...grrr... > >Henry > >Digital Infra, Inc. wrote: >> Thanks, Henry. >> >> I ran it and actually it ran on my PC. Good. >> And for a dirty bit stuff, First, check this please. >> http://lxr.linux.no/ident?i=PG_dirty >> >> --- Okajima. >> >> >> >>>http://home.arcor.de/henryn/sdl_colinux-20040730.zip >>> >>>TESTFB5.EXE: >>> Runs a SDL-Framebuffer-Daemon. >>> This starts with a colour raster and >>> wait than for update flag. >>> >>>SHM_TEST5.EXE: >>> Run this will put many rectangles into shared memory. >>> First quit some informations about shared memory with Enter key. >>> After every rectangle this will set an update bit and update >>> coordinates for rect (only one rect). >>> >>>TESTFB5F.EXE: >>> The same, but ignor rect sizes. Always update full 640x480 area. >>> Here you can verify the performance to TESTFB5.EXE. >>> >>>What do they programs? >>> Are only a simple test, how can I do connect two programs via shared >>>memory under Windows. The SDL-Daemon was compiled from linux with mingw. >>> >>>The SHM_TEST5.C simulate the update-rect from a kernel-FB-Driver in >>>frame buffer memory. >>> >>>Yes, this is all not perfect, but it's my first windows program with >>>shared memory. I have read some helps and do make up to test5. I have >>>not understand all the "virtual", "paged" and so in mailing list. Yes, I >>>know this from some kernel programmings. But in this sample I do not >>>need this. After this sample I think, it's very easy to connect colinux >>>kernel-daemon to a viewer for framebuffer. >>>I am using SDL, because it's my homebase tool for graphics. >>> >>>Please show into my source. Yes, they are not complety perfect and not >>>structured for work in real project. Many constans are hard coded, such >>>video base of 640x480x256 (8 bit) in shared memory. >>> >>>It was compiled under linux SuSE 9.0 (in a colinux box!) and I run this >>>on XP Home. My video settings in XP are 1024x768x32k (16 bit color deph). >>> >>>This sample should everybody help to understand framebuffer, and shared >>>memory problems. It's the beginning for "coLinux graphics" without VNC & >>>Co. Thanks for many ideas in the long ML-thread before! >>> >>>Nice effect: Run 2x TESTFB5.EXE and than SHM_TEST5.EXE ;-) >>> >>>Next? >>>Anybody should be give some samples, how can use dirty bit of MMU! And a >>>implementation of shared memory into colinux kernel. >>> >>>Henry >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by OSTG. Have you noticed the changes on >>>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >>>one more big change to announce. We are now OSTG- Open Source Technology >>>Group. Come see the changes on the new OSTG site. www.ostg.com >>>_______________________________________________ >>>coLinux-devel mailing list >>>coL...@li... >>>https://lists.sourceforge.net/lists/listinfo/colinux-devel >>> >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Digital I. Inc. <ok...@di...> - 2004-08-11 15:40:57
|
One thing I forgot to add. It is better to use the dirty bits from coLinux, not Windows. You can refer the bits from Windows, but maybe can not change it. Changing the bits from Windows would make inconsistency of something inside a coLinux kernel. --- Okajima. ---------------- Hello Henry. Sorry for a late reply. I can not tell you immediately how to use this bit from Windows, without searching on MSDN/DDK or such. But one thing you seem to miss --- this is not OS function, but CPU function. I dont think MS prohibits to use this function. Anyway, check here: http://www.intel.com/design/pentium4/documentation.htm http://www.intel.com/design/pentium4/manuals/index_new.htm http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html And you have "Inside NT" the definitive book of Germen edition? If not, rush to the amazon.com now. This book gives you very detailed stuff about how NT handles a dirty bit. And other issues relate to coLinux are also described well. For example, you know what "MDL" means as NT term? http://www.amazon.com/exec/obidos/search-handle-form/102-8250566-4536165 --- Okajima. >Thanks. But, how can I do this on Windows side? Have Windows also such >bit for virtual memory? >I will lock into win API again ...grrr... > >Henry > >Digital Infra, Inc. wrote: >> Thanks, Henry. >> >> I ran it and actually it ran on my PC. Good. >> And for a dirty bit stuff, First, check this please. >> http://lxr.linux.no/ident?i=PG_dirty >> >> --- Okajima. >> >> >> >>>http://home.arcor.de/henryn/sdl_colinux-20040730.zip >>> >>>TESTFB5.EXE: >>> Runs a SDL-Framebuffer-Daemon. >>> This starts with a colour raster and >>> wait than for update flag. >>> >>>SHM_TEST5.EXE: >>> Run this will put many rectangles into shared memory. >>> First quit some informations about shared memory with Enter key. >>> After every rectangle this will set an update bit and update >>> coordinates for rect (only one rect). >>> >>>TESTFB5F.EXE: >>> The same, but ignor rect sizes. Always update full 640x480 area. >>> Here you can verify the performance to TESTFB5.EXE. >>> >>>What do they programs? >>> Are only a simple test, how can I do connect two programs via shared >>>memory under Windows. The SDL-Daemon was compiled from linux with mingw. >>> >>>The SHM_TEST5.C simulate the update-rect from a kernel-FB-Driver in >>>frame buffer memory. >>> >>>Yes, this is all not perfect, but it's my first windows program with >>>shared memory. I have read some helps and do make up to test5. I have >>>not understand all the "virtual", "paged" and so in mailing list. Yes, I >>>know this from some kernel programmings. But in this sample I do not >>>need this. After this sample I think, it's very easy to connect colinux >>>kernel-daemon to a viewer for framebuffer. >>>I am using SDL, because it's my homebase tool for graphics. >>> >>>Please show into my source. Yes, they are not complety perfect and not >>>structured for work in real project. Many constans are hard coded, such >>>video base of 640x480x256 (8 bit) in shared memory. >>> >>>It was compiled under linux SuSE 9.0 (in a colinux box!) and I run this >>>on XP Home. My video settings in XP are 1024x768x32k (16 bit color deph). >>> >>>This sample should everybody help to understand framebuffer, and shared >>>memory problems. It's the beginning for "coLinux graphics" without VNC & >>>Co. Thanks for many ideas in the long ML-thread before! >>> >>>Nice effect: Run 2x TESTFB5.EXE and than SHM_TEST5.EXE ;-) >>> >>>Next? >>>Anybody should be give some samples, how can use dirty bit of MMU! And a >>>implementation of shared memory into colinux kernel. >>> >>>Henry >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by OSTG. Have you noticed the changes on >>>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >>>one more big change to announce. We are now OSTG- Open Source Technology >>>Group. Come see the changes on the new OSTG site. www.ostg.com >>>_______________________________________________ >>>coLinux-devel mailing list >>>coL...@li... >>>https://lists.sourceforge.net/lists/listinfo/colinux-devel >>> >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Chris D. <da...@ya...> - 2004-08-02 01:35:55
|
--- Henry Nestler <Hen...@ar...> wrote: > http://home.arcor.de/henryn/sdl_colinux-20040730.zip Hi Everyone, I have been lurking on the dev list for a while and would like to thank all of you for your efforts. coLinux is great and I am excited to see where it goes. I am sure that I am like many others in that I am very interested in seeing "real" graphics support. [yes, I know about vnc and cygwin/xfree :o)] I wish I knew more about programming at this level and could help out. But I don't, so I can just offer a little feedback. I downloaded the demo and it ran great on my setup... worked great. I also ran it while accessing my XP box using Remote Desktop on a 98 box and as far as I can tell, it worked great. So my point is this. It would really be nice if the ultimate graphical aspect of coLinux was compatible with Remote Desktop. I use this often and so do some of my co-workers. It is a nice and fast and can be used from any Windows PC with a single file download. I have also used the rdesktop Linux client and that works pretty well if I recall correctly. I don't know how all of this might work eventually, but it made me think of things like my tv tuner card that uses an overlay mode and so can not be used remotely. Just thought I would offer some feedback from a user's perspective while things are still in the planning stages. Thanks again! --Chris ===== There is a very fine line between "hobby" and "mental illness." --Dave Barry Linux DVDs: http://www.LinuxDVDs.com beginners robotics: http://www.robots101.com personal pages: http://www.dahlweb.net |
From: Henry N. <Hen...@ar...> - 2004-08-02 16:49:14
|
Chris Dahl wrote: > --- Henry Nestler <Hen...@ar...> wrote: > >>http://home.arcor.de/henryn/sdl_colinux-20040730.zip > > > Hi Everyone, > I have been lurking on the dev list for a while and would like to thank all > of you for your efforts. coLinux is great and I am excited to see where it > goes. > I am sure that I am like many others in that I am very interested in seeing > "real" graphics support. [yes, I know about vnc and cygwin/xfree :o)] I wish > I knew more about programming at this level and could help out. But I don't, > so I can just offer a little feedback. I downloaded the demo and it ran great > on my setup... worked great. I also ran it while accessing my XP box using > Remote Desktop on a 98 box and as far as I can tell, it worked great. > So my point is this. It would really be nice if the ultimate graphical > aspect of coLinux was compatible with Remote Desktop. I use this often and so > do some of my co-workers. It is a nice and fast and can be used from any > Windows PC with a single file download. I have also used the rdesktop Linux > client and that works pretty well if I recall correctly. > I don't know how all of this might work eventually, but it made me think of > things like my tv tuner card that uses an overlay mode and so can not be used > remotely. Just thought I would offer some feedback from a user's perspective > while things are still in the planning stages. > > Thanks again! > --Chris Oh, nice thanks for greateful feedback. I'm in beta-beta phase! The backend to graphic is the SDL-Library. So I think, give SDL your bonus. Please can you also check this parameter? Can also remote desktop? shm_test5.exe (2x ENTER, than next program) testfb5.exe -fullscreen AND testfb5.exe -hw -fullscreen After end the test, can you please send me the contens of stdout.txt? Please tell me your screen resolution and color deph of destop. What is your CPU clock, so you say FAST? On my AMD 1400 MHz the full-Update version needs 100% of CPU time. The normaly update_rects version is a little bit better, but I think, it's lose some rects, because buffer of Rects is a Pipe with one element. Henry |
From: Chris D. <da...@ya...> - 2004-08-02 23:15:40
|
> Please can you also check this parameter? Can also remote desktop? > shm_test5.exe (2x ENTER, than next program) > testfb5.exe -fullscreen > AND > testfb5.exe -hw -fullscreen > After end the test, can you please send me the contens of stdout.txt? OK... I am attaching 4 files. The file names should be self explanatory. > Please tell me your screen resolution and color deph of destop. > What is your CPU clock, so you say FAST? The reason I said that Remote Desktop is fast is that it always seems much more responsive than remote connections to Linux boxes using either Cygwin/xfree or VNC. Host Machine - P4 2.8Ghz, 1GB RAM - 1280x1024 @32bit - It has a Radeon 9000 video card. The CPU usage was increased barely 2% when running your programs. Remote Client - P120 laptop, 73Mb RAM. 800x600 @ 16bit - 802.11 connection to host at 11Mb/s. The CPU usage on this increased maybe 10% when I ran your programs through remote desktop. Maybe I am not running this correctly to see the high CPU load that you do. Let me know if you need me to do something differently. Also, I can run this from work using an 800Mhz PIII. (via remote desktop, I don't have coLinux installed there) --Chris ===== There is a very fine line between "hobby" and "mental illness." --Dave Barry Linux DVDs: http://www.LinuxDVDs.com beginners robotics: http://www.robots101.com personal pages: http://www.dahlweb.net |
From: Henry N. <Hen...@ar...> - 2004-08-03 18:18:53
|
Chris Dahl wrote: >>Please can you also check this parameter? Can also remote desktop? >> shm_test5.exe (2x ENTER, than next program) >> testfb5.exe -fullscreen >>AND >> testfb5.exe -hw -fullscreen >>After end the test, can you please send me the contens of stdout.txt? > > > OK... I am attaching 4 files. The file names should be self explanatory. > > >>Please tell me your screen resolution and color deph of destop. >>What is your CPU clock, so you say FAST? > > > The reason I said that Remote Desktop is fast is that it always seems much more > responsive than remote connections to Linux boxes using either Cygwin/xfree or > VNC. > > Host Machine - P4 2.8Ghz, 1GB RAM - 1280x1024 @32bit - It has a Radeon 9000 > video card. The CPU usage was increased barely 2% when running your programs. > > Remote Client - P120 laptop, 73Mb RAM. 800x600 @ 16bit - 802.11 connection to > host at 11Mb/s. The CPU usage on this increased maybe 10% when I ran your > programs through remote desktop. > > Maybe I am not running this correctly to see the high CPU load that you do. > Let me know if you need me to do something differently. Also, I can run this > from work using an 800Mhz PIII. (via remote desktop, I don't have coLinux > installed there) > > --Chris Chris! I'm happy for performance on your machine. Your graphic cards are mostly better as my PC. My PC use dual RAM based graphic card. The VRAM = RAM of CPU. In my PC on 1.400 MHz AMD, I can do somthing else if the reactangle way update in 100 ms steps. CPU load is 40%. This will also go better, if a real command pipe is implement for this program. That is enouth to go away this direction for real graphic under colinux. Thanks! Henry (Sorry for some mistaken in english, I'm not the best type writer. I need compiler syntax check ater write!) |
From: Digital I. Inc. <ok...@di...> - 2004-08-02 22:15:11
|
I am not sure all of what you want, but if it is like this: coLinux running on Windows with FB -> You leave from your desk -> Log in the PC from remote -> Use the PC directly when you back The answer is possible. And this is one of the reasons I decided to use a frame buffer, not Cygwin/X. And FYI, we have a plan to add a suspending function to coLinux. As current plan, a suspending image is same for all host OSes. I mean, not only all Windows, but all Linux also. In other words, you can do this: Run coLinux on Windows -> Send the image to Linux Box -> Resume there. Of course, a plan is just a plan. I can not guarantee that this will be actually implemented. But we have already confirmed that this would be possible at a technical aspect. The only issue is, who will do it. Anybody will? --- Okajima. > So my point is this. It would really be nice if the ultimate graphical >aspect of coLinux was compatible with Remote Desktop. I use this often and so >do some of my co-workers. It is a nice and fast and can be used from any >Windows PC with a single file download. I have also used the rdesktop Linux >client and that works pretty well if I recall correctly. > I don't know how all of this might work eventually, but it made me think of >things like my tv tuner card that uses an overlay mode and so can not be used >remotely. Just thought I would offer some feedback from a user's perspective >while things are still in the planning stages. > |
From: Chris D. <da...@ya...> - 2004-08-02 23:05:44
|
--- "Digital Infra, Inc." <ok...@di...> wrote: > I am not sure all of what you want, but if it is like this: > coLinux running on Windows with FB -> You leave from your desk > -> Log in the PC from remote -> Use the PC directly when you back > The answer is possible. And this is one of the reasons I decided to > use a frame buffer, not Cygwin/X. Yes, I think this is basicly what I mean. Right now I use remote desktop to access the Windows applications on my home PC when I am away from home. I leave coLinux running as a service right now, so I can also ssh to the coLinux aspect of my home PC. Now here is my dream list: * When I am at home I would like to be able to have KDE running as a windowed application that CAN be maximized to run full screen. I can do this right now using VNC or cygwin/xfree of course. * I would also love to be able to run individual applications from coLinux as individual Windows windows. This would be a similar behavior to a "rootless" cygwin/x session. But without the "sluggishness" or the need to have cygwin or VNC installed. * AND when I am away from my computer, I would like to be able to use remote desktop to connect to my windows desktop. And then run and view KDE and/or other Linux applications as described above... within the Windows remote desktop session. Like I said, this is just my dream list. I know that some applications don't play well with remote desktop. And I wouldn't complain if coLinux was ultimately one of these applications. It is already wonderful and I am greatful to have it. Thanks Again! --Chris ===== There is a very fine line between "hobby" and "mental illness." --Dave Barry Linux DVDs: http://www.LinuxDVDs.com beginners robotics: http://www.robots101.com personal pages: http://www.dahlweb.net |
From: Digital I. Inc. <ok...@di...> - 2004-08-02 23:12:49
|
First, read these. http://marc.theaimsgroup.com/?l=colinux-devel&m=108920889621282&w=2 http://www.digitalinfra.co.jp/overlapping.png And I guess that all of your wish can be achieved some day. --- Okajima. >--- "Digital Infra, Inc." <ok...@di...> wrote: >> I am not sure all of what you want, but if it is like this: >> coLinux running on Windows with FB -> You leave from your desk >> -> Log in the PC from remote -> Use the PC directly when you back >> The answer is possible. And this is one of the reasons I decided to >> use a frame buffer, not Cygwin/X. > >Yes, I think this is basicly what I mean. Right now I use remote desktop to >access the Windows applications on my home PC when I am away from home. > >I leave coLinux running as a service right now, so I can also ssh to the >coLinux aspect of my home PC. > >Now here is my dream list: > >* When I am at home I would like to be able to have KDE running as a windowed >application that CAN be maximized to run full screen. I can do this right now >using VNC or cygwin/xfree of course. > >* I would also love to be able to run individual applications from coLinux as >individual Windows windows. This would be a similar behavior to a "rootless" >cygwin/x session. But without the "sluggishness" or the need to have cygwin or >VNC installed. > >* AND when I am away from my computer, I would like to be able to use remote >desktop to connect to my windows desktop. And then run and view KDE and/or >other Linux applications as described above... within the Windows remote >desktop session. > >Like I said, this is just my dream list. I know that some applications don't >play well with remote desktop. And I wouldn't complain if coLinux was >ultimately one of these applications. It is already wonderful and I am >greatful to have it. > >Thanks Again! >--Chris > >===== >There is a very fine line between "hobby" and "mental illness." --Dave Barry >Linux DVDs: http://www.LinuxDVDs.com >beginners robotics: http://www.robots101.com >personal pages: http://www.dahlweb.net > |
From: Nuno L. <nt...@nl...> - 2004-08-10 09:44:16
|
After looking at the CoLinux FB demo (prototype?) I tried to make it work with some of the ideas I had, but SDL doesn't seem to accept transparent windows of any form (it seems the fault is that DirectX doesn't cooperate very well with the basic GDI). I finally decided to start a project from scratch to test my ideas, and this is result. Attached is the source code and two binaries. I used VS .NET only, so it's normal that the code needs to be modified to build on mingw32. * cofb.exe is the FB viewer. If you start it before the driver you need to attach it, using the menu command. * cofb_driver.exe is the driver. By default it creates a 640x480x24 shared FB, but you can customize it by giving it the values desired (only 16, 24 & 32 bpp, for now). As an example: "cofb_driver 800 600 16". The program uses a 32 rects long queue for invalidating only partial areas; has locking capabilities (only basic locking, for now); back buffer for fast graphics (using directly the shared FB); random pixels demo; random boxes demo; bouncing box demo & random position transparent boxes. Also it's pure Win32 API, no MFC here. One thing I think I see is that with a modern video card (ATI Radeon 9600 SE), it doesn't seem to have much difference updating all or part of the window. You can check this by enabling all tests simultaneously (random pixels mark all screen for refresh). Please take a look and feel free to give your opinion. NOTE: This it's only meant to work with Win2000/XP. Regards, ~Nuno Lucas |
From: Nuno L. <nt...@nl...> - 2004-08-10 10:01:07
|
No zips here, so you can download it from: http://quixote.planetaclix.pt/cofb.zip Regards, ~Nuno Lucas Nuno Lucas, dando pulos de alegria, escreveu : > After looking at the CoLinux FB demo (prototype?) I tried to make it > work with some of the ideas I had, but SDL doesn't seem to accept > transparent windows of any form (it seems the fault is that DirectX > doesn't cooperate very well with the basic GDI). > > I finally decided to start a project from scratch to test my ideas, and > this is result. > > Attached is the source code and two binaries. I used VS .NET only, so > it's normal that the code needs to be modified to build on mingw32. > > * cofb.exe is the FB viewer. If you start it before the driver you need > to attach it, using the menu command. > > * cofb_driver.exe is the driver. By default it creates a 640x480x24 > shared FB, but you can customize it by giving it the values desired > (only 16, 24 & 32 bpp, for now). > As an example: "cofb_driver 800 600 16". > > The program uses a 32 rects long queue for invalidating only partial > areas; has locking capabilities (only basic locking, for now); back > buffer for fast graphics (using directly the shared FB); random pixels > demo; random boxes demo; bouncing box demo & random position transparent > boxes. Also it's pure Win32 API, no MFC here. > > One thing I think I see is that with a modern video card (ATI Radeon > 9600 SE), it doesn't seem to have much difference updating all or part > of the window. You can check this by enabling all tests simultaneously > (random pixels mark all screen for refresh). > > Please take a look and feel free to give your opinion. > > NOTE: This it's only meant to work with Win2000/XP. > > Regards, > ~Nuno Lucas |
From: Digital I. Inc. <ok...@di...> - 2004-08-10 15:51:17
|
Okay, it ran on my PC. And I understand that you and Henry can do all the stuff about SDL, including an overlapping (multi) window stuff. Then, the issue could go to who makes a shared buffer. Ummmm..... Who??? Is it a guy in Tokyo, Japan ?. Ummm.... --- Okajima. >No zips here, so you can download it from: > >http://quixote.planetaclix.pt/cofb.zip > >Regards, >~Nuno Lucas > > >Nuno Lucas, dando pulos de alegria, escreveu : >> After looking at the CoLinux FB demo (prototype?) I tried to make it >> work with some of the ideas I had, but SDL doesn't seem to accept >> transparent windows of any form (it seems the fault is that DirectX >> doesn't cooperate very well with the basic GDI). >> >> I finally decided to start a project from scratch to test my ideas, and >> this is result. >> >> Attached is the source code and two binaries. I used VS .NET only, so >> it's normal that the code needs to be modified to build on mingw32. >> >> * cofb.exe is the FB viewer. If you start it before the driver you need >> to attach it, using the menu command. >> >> * cofb_driver.exe is the driver. By default it creates a 640x480x24 >> shared FB, but you can customize it by giving it the values desired >> (only 16, 24 & 32 bpp, for now). >> As an example: "cofb_driver 800 600 16". >> >> The program uses a 32 rects long queue for invalidating only partial >> areas; has locking capabilities (only basic locking, for now); back >> buffer for fast graphics (using directly the shared FB); random pixels >> demo; random boxes demo; bouncing box demo & random position transparent >> boxes. Also it's pure Win32 API, no MFC here. >> >> One thing I think I see is that with a modern video card (ATI Radeon >> 9600 SE), it doesn't seem to have much difference updating all or part >> of the window. You can check this by enabling all tests simultaneously >> (random pixels mark all screen for refresh). >> >> Please take a look and feel free to give your opinion. >> >> NOTE: This it's only meant to work with Win2000/XP. >> >> Regards, >> ~Nuno Lucas > > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Hen...@ar...> - 2004-08-11 08:42:46
|
SDL must not understand. It was only my simple graphic tool for window and linux, before Nuna present his sample with using _BitBlt_ :-) under Windows. Henry Digital Infra, Inc. wrote: > > Okay, it ran on my PC. > And I understand that you and Henry can do all the stuff about SDL, > including an overlapping (multi) window stuff. > Then, the issue could go to who makes a shared buffer. > Ummmm..... Who??? Is it a guy in Tokyo, Japan ?. Ummm.... > > --- Okajima. > > > >>No zips here, so you can download it from: >> >>http://quixote.planetaclix.pt/cofb.zip >> >>Regards, >>~Nuno Lucas >> >> >>Nuno Lucas, dando pulos de alegria, escreveu : >> >>>After looking at the CoLinux FB demo (prototype?) I tried to make it >>>work with some of the ideas I had, but SDL doesn't seem to accept >>>transparent windows of any form (it seems the fault is that DirectX >>>doesn't cooperate very well with the basic GDI). >>> >>>I finally decided to start a project from scratch to test my ideas, and >>>this is result. >>> >>>Attached is the source code and two binaries. I used VS .NET only, so >>>it's normal that the code needs to be modified to build on mingw32. >>> >>>* cofb.exe is the FB viewer. If you start it before the driver you need >>>to attach it, using the menu command. >>> >>>* cofb_driver.exe is the driver. By default it creates a 640x480x24 >>>shared FB, but you can customize it by giving it the values desired >>>(only 16, 24 & 32 bpp, for now). >>>As an example: "cofb_driver 800 600 16". >>> >>>The program uses a 32 rects long queue for invalidating only partial >>>areas; has locking capabilities (only basic locking, for now); back >>>buffer for fast graphics (using directly the shared FB); random pixels >>>demo; random boxes demo; bouncing box demo & random position transparent >>>boxes. Also it's pure Win32 API, no MFC here. >>> >>>One thing I think I see is that with a modern video card (ATI Radeon >>>9600 SE), it doesn't seem to have much difference updating all or part >>>of the window. You can check this by enabling all tests simultaneously >>>(random pixels mark all screen for refresh). >>> >>>Please take a look and feel free to give your opinion. >>> >>>NOTE: This it's only meant to work with Win2000/XP. >>> >>>Regards, >>>~Nuno Lucas >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >>_______________________________________________ >>coLinux-devel mailing list >>coL...@li... >>https://lists.sourceforge.net/lists/listinfo/colinux-devel >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Hen...@ar...> - 2004-08-11 08:16:21
|
Hello Nuno, very nice! Random boxes use 49% of CPU, if cofb.exe displayed in foreground. (default resolution, 1.800MHz Pentium 4, 224MB RAM, SiS 650 Graphic chip shared VRAM 32MB, XP Home) Your function BitBlt is better and faster as my SDL test. SDL I'm using only, because I do not know such beautiful windows function. After your sample, I say, we should use BitBlt() instand of SDL. [ Subject changed ;-) ] Your random pixel: Yes, this was also my problem. I know, that some application do only write into framebuffer and do not call any function to trigger an update. For better performance we can use a shadow buffer behind the BackBuffer. This buffers can compare in a interval time (i.g. all 500ms) and update only a calculated rect over all changed pixels. Or a update line by line, if any pixel changed. This is not the best, but I have absoluty no other ideas to optimize "random-pixel-applicatons". Hope, anybody can tell us, ho we can access the "dirty bit of MMU" on linux- or windows side. (Mail from You and Okajima) I'm yust reading windows API for function BitBlt() again. Is this right, that WHITENESS fill the box with color? Can we use this for clear screen and some other accelorated function such in "cofb_fillrect"? Sample: The Linuxdriver fill completly the rect with colour (or only bit on position 1,1) and on Windows using WHITENESS. This needs a command fifo from colinuxFB (your cofb_driver.exe) to windows. You wrote, we can using the 31th bit for "command" (in old mail). Nice idea, but are 4x32 Bits enough for some other accelorate commands? ... ok, that are some things for next steps, but think after first running "colinuxFB". Henry Nuno Lucas wrote: > No zips here, so you can download it from: > > http://quixote.planetaclix.pt/cofb.zip > > Regards, > ~Nuno Lucas > > > Nuno Lucas, dando pulos de alegria, escreveu : > >> After looking at the CoLinux FB demo (prototype?) I tried to make it >> work with some of the ideas I had, but SDL doesn't seem to accept >> transparent windows of any form (it seems the fault is that DirectX >> doesn't cooperate very well with the basic GDI). >> >> I finally decided to start a project from scratch to test my ideas, >> and this is result. >> >> Attached is the source code and two binaries. I used VS .NET only, so >> it's normal that the code needs to be modified to build on mingw32. >> >> * cofb.exe is the FB viewer. If you start it before the driver you >> need to attach it, using the menu command. >> >> * cofb_driver.exe is the driver. By default it creates a 640x480x24 >> shared FB, but you can customize it by giving it the values desired >> (only 16, 24 & 32 bpp, for now). >> As an example: "cofb_driver 800 600 16". >> >> The program uses a 32 rects long queue for invalidating only partial >> areas; has locking capabilities (only basic locking, for now); back >> buffer for fast graphics (using directly the shared FB); random pixels >> demo; random boxes demo; bouncing box demo & random position >> transparent boxes. Also it's pure Win32 API, no MFC here. >> >> One thing I think I see is that with a modern video card (ATI Radeon >> 9600 SE), it doesn't seem to have much difference updating all or part >> of the window. You can check this by enabling all tests simultaneously >> (random pixels mark all screen for refresh). >> >> Please take a look and feel free to give your opinion. >> >> NOTE: This it's only meant to work with Win2000/XP. >> >> Regards, >> ~Nuno Lucas > |
From: Nuno L. <nt...@nl...> - 2004-08-11 10:39:48
|
Henry Nestler, dando pulos de alegria, escreveu : > Hello Nuno, > > very nice! > Random boxes use 49% of CPU, if cofb.exe displayed in foreground. > (default resolution, 1.800MHz Pentium 4, 224MB RAM, SiS 650 Graphic chip > shared VRAM 32MB, XP Home) In my computer it would give me about 10-15%, I think a sign of my "modern" video card (and your shared VRAM). The FB "viewer" and the test driver are in a constant loop, sleeping only enough to let other threads run (50 ms the viewer, 5 ms the test driver). This would need to be refined later, off course. > Your function BitBlt is better and faster as my SDL test. SDL I'm using > only, because I do not know such beautiful windows function. > After your sample, I say, we should use BitBlt() instand of SDL. > [ Subject changed ;-) ] As I wrote in another mail, it's not really the BitBlt that is making this. Please take a look at the "CreateDIBSection" thread. > Your random pixel: > Yes, this was also my problem. I know, that some application do only > write into framebuffer and do not call any function to trigger an update. > For better performance we can use a shadow buffer behind the BackBuffer. > This buffers can compare in a interval time (i.g. all 500ms) and update > only a calculated rect over all changed pixels. Or a update line by > line, if any pixel changed. > > This is not the best, but I have absoluty no other ideas to optimize > "random-pixel-applicatons". Hope, anybody can tell us, ho we can access > the "dirty bit of MMU" on linux- or windows side. (Mail from You and > Okajima) Yes, this seems the right place were this method shines. I think this is mostly only for console applications that use the FB directly. In theory, the XFB server would know better. > I'm yust reading windows API for function BitBlt() again. Is this right, > that WHITENESS fill the box with color? Can we use this for clear screen > and some other accelorated function such in "cofb_fillrect"? > Sample: The Linuxdriver fill completly the rect with colour (or only bit > on position 1,1) and on Windows using WHITENESS. I'm not following you. WHITENESS and BLACKNESS were more used for palleted bitmaps, where pallet color 0 were black by default and color 1 was white by default. I confess I don't know how they are used now with 32 bit colors (never used them). To clear the screen, simply memset(&fb_bits,0,pitch*height). I can't imagine a fastest way of doing it (it was slower in the old days of EGA/VGA color planes). I think you are confusing Device Contexts with Bitmaps. BitBlt works with Device Contexts, not Bitmaps. For raw bitmap access we are on our own. Off course there should be lots of libraries for doing this in an optimal way (I remember FreeImage as a good open source library, but I have no idea of what routines they have for this). > This needs a command fifo from colinuxFB (your cofb_driver.exe) to > windows. You wrote, we can using the 31th bit for "command" (in old > mail). Nice idea, but are 4x32 Bits enough for some other accelorate > commands? ... ok, that are some things for next steps, but think after > first running "colinuxFB". Well, we can see the rect queue as a 128 bit meta-instructions queue. It doesn't matter if one instruction doesn't fit in 128 bits because we simply continue on the next (it's only up to the parser). But for this we would need much more than the 32 slots I currently use (I already let 4KB for the header and use only a small part). I think the best would be to study the use the XFB server makes of the FB driver. Then we can make a good analysis of the best syntax we would allow. Regards, ~Nuno Lucas |
From: Henry N. <Hen...@ar...> - 2004-08-16 16:53:43
|
Nuno Lucas wrote: > Hi Henry. > [...] > I was experimenting with the vfb module, but couldn't get it to work. > > As you said you already made a fb driver for linux I was wondering if > you could shed some light on my head about this (I have never messed > with FB before). > > Regards, > ~Nuno Lucas vbf, the virtual framebuffer, does not work. It's to simple. This is also not a good sample for new devices. Better is to use vesafb. Yes, I have implement a framebuffer driver on non standard hardware. This hardware has no real VRAM. So I have do this with one buffer as FB-RAM and an other buffer as shadow-RAM. In a timer funtion I have update the different lines to real hardware (byte by byte). This ideas I can also use for coLinux FB. If this works, we can implement the "Durty Bit of MMU". I will make a simple demo of FB module. This should share the FB-buffer with a simple SDL-Viewer. Only runs under Linux. My favorite Graphic tool is SDL, so I use SDL for viewing. Give me 3-5 days for first output. OK? Henry |
From: Nuno L. <lu...@nl...> - 2004-08-16 21:57:41
|
Henry Nestler, dando pulos de alegria, escreveu : > vbf, the virtual framebuffer, does not work. It's to simple. This is > also not a good sample for new devices. Better is to use vesafb. ok. vesafb has a problem, though: it doesn't let change resolution without rebooting. For testing purposes it would be better if we could load/unload the module at will with different resolutions. But that can always be added latter, off course. > [...] > I will make a simple demo of FB module. This should share the FB-buffer > with a simple SDL-Viewer. Only runs under Linux. My favorite Graphic > tool is SDL, so I use SDL for viewing. Give me 3-5 days for first > output. OK? Go for it! (but no need to rush ;) Regards, ~Nuno Lucas |