From: Anders E. C (KI/EAB) <and...@er...> - 2004-08-17 07:55:29
|
> 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. > Just a heads up. Recent discussion on lkml indicates activities picking up in the DRM camp. My understanding (not knowning the details) is that the new DRM implementation will/may replace the fb stuff, so you may not want to bet the farm on the survival of existing fb APIs etc... /A |
From: Nuno L. <lu...@nl...> - 2004-08-17 10:24:09
|
Anders Eriksson C (KI/EAB), dando pulos de alegria, escreveu : > Just a heads up. Recent discussion on lkml indicates activities > picking up in the DRM camp. My understanding (not knowning the details) > is that the new DRM implementation will/may replace the fb stuff, so > you may not want to bet the farm on the survival of existing fb APIs etc... > > /A That is a good point. I think we can still go the fb way as a start, as the implementation is easy enough as long as we get the win/colinux shared memory issue settled. On a more long term project, we need to look at DRM. I was browsing the DRM/DRI/FB issue and found this links which I think can be relevant to the interested parties: [1] OLS and console re architecture http://lkml.org/lkml/2004/8/2/111 [2] DRM reorganization http://thread.gmane.org/gmane.comp.video.dri.devel/11447 [3] (unknown) (DRM patch) http://thread.gmane.org/gmane.linux.kernel/225969 [4] Re: DRM function pointer work.. http://lkml.org/lkml/2004/8/6/155 From what I see, there is yet work to be done before we can expect a "clean" DRM kernel development, but it's a thing to keep an eye on the future. Regards, ~Nuno Lucas |
From: Digital I. Inc. <ok...@di...> - 2004-08-17 17:15:29
|
> >I think we can still go the fb way as a start, as the implementation is >easy enough as long as we get the win/colinux shared memory issue settled. > Current my plan about the shared buf stuff is: - Allocating the mem on coLinux virtual address space. Therefore, you can access it normally inside coLinux. - Usually, you need to mlock() there. But you can swap it out if you dont display it. - By adding "peeping coLinux virtual physical memory from Windows" func to linux.sys, you can see the mem from Win32 world, if you are in ring 0. - from Linux side, what you would do is like this: ( this is for a demo code. not for actual frame buffer driver code.) start: malloc( fb_x * fb_y / fb_depth * 8 ); mlock(); wirte_pixels(); for(each page) if(is_dirty(page)){ push_queue(line, phy_adr(page)); reset_dirty(page);} flush_queue(); unlock(); // here you can swap a fb out. free(fb); end: Some problems I still have : - Is it Okay to call Direct/X funcs from ring 0? - Can Direct/X handle bitmaps on ring 0? --- Okajima. |
From: Nuno L. <lu...@nl...> - 2004-08-17 19:17:55
|
Digital Infra, Inc., dando pulos de alegria, escreveu : >>I think we can still go the fb way as a start, as the implementation is >>easy enough as long as we get the win/colinux shared memory issue settled. > > Current my plan about the shared buf stuff is: > > - Allocating the mem on coLinux virtual address space. > Therefore, you can access it normally inside coLinux. > - Usually, you need to mlock() there. But you can swap it out > if you dont display it. > - By adding "peeping coLinux virtual physical memory from Windows" func > to linux.sys, you can see the mem from Win32 world, if you are in ring 0. > - from Linux side, what you would do is like this: > ( this is for a demo code. not for actual frame buffer driver code.) > > start: > malloc( fb_x * fb_y / fb_depth * 8 ); > mlock(); > wirte_pixels(); > for(each page) > if(is_dirty(page)){ push_queue(line, phy_adr(page)); > reset_dirty(page);} > flush_queue(); > unlock(); > // here you can swap a fb out. > free(fb); > end: > > > Some problems I still have : > - Is it Okay to call Direct/X funcs from ring 0? > - Can Direct/X handle bitmaps on ring 0? DirectX is a user level library, just like DirectFB is a user level library that calls kernel functions exported by the fb driver. On ring 0 you have to talk with the low level GDI engine, but there is no window handling there (that is user level stuf), only lowlevel GDI surfaces. The GDI engine includes low level bitmap handling functions. What does the mlock()/unlock() functions do, exactly? Regards, ~Nuno Lucas |
From: Digital I. Inc. <ok...@di...> - 2004-08-18 17:18:47
|
> >DirectX is a user level library, just like DirectFB is a user level >library that calls kernel functions exported by the fb driver. > >On ring 0 you have to talk with the low level GDI engine, but there is >no window handling there (that is user level stuf), only lowlevel GDI >surfaces. > >The GDI engine includes low level bitmap handling functions. > Okay, I suppose that you have some knowledge about this stuff. Can I count on it? >What does the mlock()/unlock() functions do, exactly? > > You must have the answer on you HDD. Type $ man mlock. --- Okajima. |
From: Nuno L. <lu...@nl...> - 2004-08-19 12:42:47
|
Digital Infra, Inc., dando pulos de alegria, escreveu : >>DirectX is a user level library, just like DirectFB is a user level >>library that calls kernel functions exported by the fb driver. >> >>On ring 0 you have to talk with the low level GDI engine, but there is >>no window handling there (that is user level stuf), only lowlevel GDI >>surfaces. >> >>The GDI engine includes low level bitmap handling functions. > > Okay, I suppose that you have some knowledge about this stuff. > Can I count on it? I just have MSDN and that is what I understood from it. >>What does the mlock()/unlock() functions do, exactly? > > You must have the answer on you HDD. Type $ man mlock. Oops, I was thinking it were some linux kernel routine. About mapping kernel memory to a user process address space, I know (from the MSDN) that you can use the Zw* functions to accomplish this. A link to a basic howto on this is at: http://support.microsoft.com/default.aspx?scid=kb;en-us;191840 ~Nuno Lucas |
From: Nuno L. <lu...@nl...> - 2004-08-19 13:03:48
|
Nuno Lucas, dando pulos de alegria, escreveu : > About mapping kernel memory to a user process address space, I know > (from the MSDN) that you can use the Zw* functions to accomplish this. > > A link to a basic howto on this is at: > http://support.microsoft.com/default.aspx?scid=kb;en-us;191840 A better link is: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/memmgmt_80dc22f4-ce30-42b4-9c82-1f0e4b2bf180.xml.asp Regards, ~Nuno Lucas |
From: Sam L. <sa...@li...> - 2004-08-17 22:07:18
|
Digital Infra, Inc. wrote: > Some problems I still have : > - Is it Okay to call Direct/X funcs from ring 0? > - Can Direct/X handle bitmaps on ring 0? You won't want to, but from ring 0 you should be able to allocate some process address space that maps to this shared memory. I last did this sort of thing in 16 bit windows and DPMI so I am a bit hazy on details. Sam |
From: Digital I. Inc. <ok...@di...> - 2004-08-18 17:18:59
|
>Digital Infra, Inc. wrote: > >> Some problems I still have : >> - Is it Okay to call Direct/X funcs from ring 0? >> - Can Direct/X handle bitmaps on ring 0? > >You won't want to, but from ring 0 you should be able to allocate some >process address space that maps to this shared memory. >I last did this sort of thing in 16 bit windows and DPMI so I am a bit >hazy on details. > Good! Can you tell me the API of doing that allocation? If the api you would tell me is as same as what I imagine now, We can access all of coLinux virtual physical memory pages from a user land daemon. And probably the pages can be contiguous. Good. --- Okajima. |
From: Sam L. <sa...@li...> - 2004-08-19 12:27:45
|
Digital Infra, Inc. wrote: >>Digital Infra, Inc. wrote: >> >> >>>Some problems I still have : >>> - Is it Okay to call Direct/X funcs from ring 0? >>> - Can Direct/X handle bitmaps on ring 0? >> >>You won't want to, but from ring 0 you should be able to allocate some >>process address space that maps to this shared memory. >>I last did this sort of thing in 16 bit windows and DPMI so I am a bit >>hazy on details. > > Good! Can you tell me the API of doing that allocation? Alas no, my stuff was all windows 3.1 and DPMI 0.9 The best I can give you is this link to the docs I was using: http://www.tenberry.com/dpmi/08.html > If the api you would tell me is as same as what I imagine now, > We can access all of coLinux virtual physical memory pages from > a user land daemon. And probably the pages can be contiguous. Good. I think the best place to ask the question is the msdn.microsoft.com Try looking at things like: MmMapLockedPages http://support.microsoft.com/default.aspx?scid=kb;en-us;189327 http://support.microsoft.com/default.aspx?scid=kb;en-us;124137 Also see the related menu items in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k106_fc92914d-81c3-4ae9-a12d-86003d55bb4d.xml.asp I am curious why we are in this situation; why don't the userland graphics daemon and the coLinux daemon just use regular windows shared memory between them? Sam |
From: Digital I. Inc. <ok...@di...> - 2004-08-19 13:14:19
|
> >I am curious why we are in this situation; why don't the userland >graphics daemon and the coLinux daemon just use regular windows shared >memory between them? > The problem is not how to share a memory between Windows processes, but how to share a memory between coLinux world and Win32 world. coLinux memory stays on kernel space as a special AGP texture memory. So the problem is same as how to map an AGP texture memory to a user land process. --- Okajima. |
From: Sam L. <sa...@li...> - 2004-08-19 15:52:37
|
Digital Infra, Inc. wrote: >>I am curious why we are in this situation; why don't the userland >>graphics daemon and the coLinux daemon just use regular windows shared >>memory between them? >> >> >> > >The problem is not how to share a memory between Windows processes, but >how to share a memory between coLinux world and Win32 world. >coLinux memory stays on kernel space as a special AGP texture memory. >So the problem is same as how to map an AGP texture memory to a user land process. > > (If I'm talking through my hat, please ignore me and I'll go away quietly; I'm just trying to be helpful while being 8 years out of date) Maybe something like: MmMapUserAddressesToPage Is the sort of thing you need? http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=054201c34fcd%24c43b81b0%24a101280a%40phx.gbl&rnum=1&prev=/groups%3Fq%3DMmMapUserAddressesToPage%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D054201c34fcd%2524c43b81b0%2524a101280a%2540phx.gbl%26rnum%3D1 MmGetPhysicalAddress http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k106_fc92914d-81c3-4ae9-a12d-86003d55bb4d.xml.asp Also: *MmGetSystemAddressForMdlSafe* maps the physical pages described by a given MDL into system space, if they are not already mapped to system space. Drivers of PIO devices call this routine to translate a virtual address range, described by the MDL at *Irp->MdlAddress*, for a user buffer to a system-space address range. MmGetSystemAddressForMdlSafe maps the physical pages described by a given MDL into system space, if they are not already mapped to system space. Drivers of PIO devices call this routine to translate a virtual address range, described by the MDL at Irp->MdlAddress, for a user buffer to a system-space address range. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k106_7fded087-cd2f-40a9-9f66-6cfaa9e5ead9.xml.asp MmGetPhysicalAddressMmGetPhysicalAddress |
From: Digital I. Inc. <ok...@di...> - 2004-08-20 16:42:04
|
>(If I'm talking through my hat, please ignore me and I'll go away >quietly; I'm just trying to be helpful while being 8 years out of date) Not at all! your advice is very useful. I have not checked your suggestion well, but APIs you suggested is very close to what I want. Maybe it is just what I want. I can not find how to use "MmMapUserAddressesToPage", but if it can map pages on kernle space described by MDL to a user space, every prolem solves. In other words, I just want to map this "PMDL mdl" to my user space daemon!. this "PMDL mdl" holds all infomation about coLinux virtual physical pages. extracted from src/colinux/os/winnt/kernel/alloc.c > co_rc_t co_os_get_page(struct co_manager *manager, co_pfn_t *pfn) > { > PMDL mdl; > mdl = MmAllocatePagesForMdl(LowAddress, > HighAddress, > SkipBytes, > PAGE_SIZE); > } --- Okajima. |
From: Marc-Antoine R. <ma...@eo...> - 2004-09-17 18:21:00
|
Here is the prototype I could find out (unverified, never tested): NTSTATUS __stdcall MmMapUserAddressesToPage(PVOID BaseAddress,SIZE_T NumberOfBytes,PVOID PageAddress); - BaseAddress must be user-mode. - I think PageAddress should be locked in memory because it is directly passed to MmGetPhysicalAddress(PageAddress); You can try without locking it. Never tried anyway. but you may use : MmSecureVirtualMemory(); MmMapLockedPagesSpecifyCache(); MmUnsecureVirtualMemory(); When done, do MmUnmapLockedPages() Still haven't tried anything of that, but I'm about to do so. The problem is, indeed, that the pages must be locked in memory... In the first case, maybe you can unlock the pages after doing the call but I'm not sure. Marc-Antoine Ruel "Digital Infra, Inc." <ok...@di...> wrote in message news:200...@wi...... > > >(If I'm talking through my hat, please ignore me and I'll go away > >quietly; I'm just trying to be helpful while being 8 years out of date) > > Not at all! your advice is very useful. > > I have not checked your suggestion well, but APIs you suggested is > very close to what I want. Maybe it is just what I want. > I can not find how to use "MmMapUserAddressesToPage", but if it can > map pages on kernle space described by MDL to a user space, > every prolem solves. > > In other words, I just want to map this "PMDL mdl" to my user space daemon!. > this "PMDL mdl" holds all infomation about coLinux virtual physical pages. > > extracted from src/colinux/os/winnt/kernel/alloc.c > > co_rc_t co_os_get_page(struct co_manager *manager, co_pfn_t *pfn) > > { > > PMDL mdl; > > mdl = MmAllocatePagesForMdl(LowAddress, > > HighAddress, > > SkipBytes, > > PAGE_SIZE); > > } > > > --- Okajima. |
From: Digital I. Inc. <ok...@di...> - 2004-09-18 17:19:28
|
GOOOD! thanks. and hopefully a kind hacker gives the running code. but, anyway, take it easy. someone including me must write a shared buf code soon, because most problems are solved. --- Okajima. >Here is the prototype I could find out (unverified, never tested): >NTSTATUS __stdcall MmMapUserAddressesToPage(PVOID BaseAddress,SIZE_T >NumberOfBytes,PVOID PageAddress); > - BaseAddress must be user-mode. > - I think PageAddress should be locked in memory because it is directly >passed to MmGetPhysicalAddress(PageAddress); You can try without locking it. >Never tried anyway. > >but you may use : >MmSecureVirtualMemory(); >MmMapLockedPagesSpecifyCache(); >MmUnsecureVirtualMemory(); >When done, do MmUnmapLockedPages() > >Still haven't tried anything of that, but I'm about to do so. The problem >is, indeed, that the pages must be locked in memory... In the first case, >maybe you can unlock the pages after doing the call but I'm not sure. > >Marc-Antoine Ruel > >"Digital Infra, Inc." <ok...@di...> wrote in message >news:200...@wi...... >> >> >(If I'm talking through my hat, please ignore me and I'll go away >> >quietly; I'm just trying to be helpful while being 8 years out of date) >> >> Not at all! your advice is very useful. >> >> I have not checked your suggestion well, but APIs you suggested is >> very close to what I want. Maybe it is just what I want. >> I can not find how to use "MmMapUserAddressesToPage", but if it can >> map pages on kernle space described by MDL to a user space, >> every prolem solves. >> >> In other words, I just want to map this "PMDL mdl" to my user space >daemon!. >> this "PMDL mdl" holds all infomation about coLinux virtual physical pages. >> >> extracted from src/colinux/os/winnt/kernel/alloc.c >> > co_rc_t co_os_get_page(struct co_manager *manager, co_pfn_t *pfn) >> > { >> > PMDL mdl; >> > mdl = MmAllocatePagesForMdl(LowAddress, >> > HighAddress, >> > SkipBytes, >> > PAGE_SIZE); >> > } >> >> >> --- Okajima. > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > |