From: Denis O. K. <do...@di...> - 2003-04-25 11:07:47
|
Hi, I want to begin with the seperation of the drivers from MiniGLX by putting a generic layer between them. The goal is to be able to build the libGL without MiniGLX at all. The drivers in src/drv should not know about MiniGLXDisplayRec, they are currently using the following members: dok@skunk[~/cvs/Mesa/src/drv] cgrep 'dpy->' | perl -p -i -e 's/.*(dpy\-\>[\w\.]+).*/\1/g' | sort -u dpy->bpp dpy->chipset dpy->cpp dpy->driverClientMsg dpy->driverClientMsgSize dpy->driverInfo dpy->drmFD dpy->FixedInfo.mmio_len dpy->FixedInfo.mmio_start dpy->FixedInfo.smem_len dpy->FixedInfo.smem_start dpy->FrameBuffer dpy->IsClient dpy->MMIOAddress dpy->pciBus dpy->pciBusID dpy->pciChipType dpy->pciDevice dpy->pciFunc dpy->pciVendor dpy->pSAREA dpy->shared.fbSize dpy->shared.hFrameBuffer dpy->shared.hSAREA dpy->shared.SAREASize dpy->shared.virtualHeight dpy->shared.virtualWidth dpy->TheWindow As a starting point I would like to put these members into a generic structure and pass it to the drivers. This should have no impact on the current implementation and is a step forward to the proposed tree reorganization. What do you think? Further steps are a bit more complicated, dpy->TheWindow is still MiniGLX specific (MiniGLXWindowRec) and that in turn requires more X11 style stuff like visuals etc. But as far as I've looked through the drivers they only need "TheWindow" in the vt switching callback. I will just start working on that, comments or corrections are welcome. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH |
From: Keith W. <ke...@tu...> - 2003-04-25 11:18:18
|
Denis Oliver Kropp wrote: > Hi, > > I want to begin with the seperation of the drivers from > MiniGLX by putting a generic layer between them. The goal > is to be able to build the libGL without MiniGLX at all. > > The drivers in src/drv should not know about MiniGLXDisplayRec, > they are currently using the following members: > > dok@skunk[~/cvs/Mesa/src/drv] cgrep 'dpy->' | perl -p -i -e 's/.*(dpy\-\>[\w\.]+).*/\1/g' | sort -u > dpy->bpp > dpy->chipset > dpy->cpp > dpy->driverClientMsg > dpy->driverClientMsgSize > dpy->driverInfo > dpy->drmFD > dpy->FixedInfo.mmio_len > dpy->FixedInfo.mmio_start > dpy->FixedInfo.smem_len > dpy->FixedInfo.smem_start > dpy->FrameBuffer > dpy->IsClient > dpy->MMIOAddress > dpy->pciBus > dpy->pciBusID > dpy->pciChipType > dpy->pciDevice > dpy->pciFunc > dpy->pciVendor > dpy->pSAREA > dpy->shared.fbSize > dpy->shared.hFrameBuffer > dpy->shared.hSAREA > dpy->shared.SAREASize > dpy->shared.virtualHeight > dpy->shared.virtualWidth > dpy->TheWindow > > As a starting point I would like to put these members into a generic > structure and pass it to the drivers. This should have no impact on > the current implementation and is a step forward to the proposed tree > reorganization. What do you think? Anything in this direction should also include allowing the driver to be used as a straightforward DRI driver - which is a bit complex as this will require a little shuffling of what is part of the driver & what is part of libGL.so. But generally I like the idea of having the drivers be window-system independent. > Further steps are a bit more complicated, dpy->TheWindow is still MiniGLX > specific (MiniGLXWindowRec) and that in turn requires more X11 style stuff > like visuals etc. But as far as I've looked through the drivers they only > need "TheWindow" in the vt switching callback. The VT switching stuff is subject to flux at the moment. (A lot of this is driven by customer requirements for a TG project). > I will just start working on that, comments or corrections are welcome. I'm about to commit a bunch of changes that allow (actually require atm, but that should change) the use of a "server" process which init's fbdev & manages a single fullscreen cliprect, and allows non-root clients. Keith |
From: Holger W. <ho...@co...> - 2003-04-25 11:28:41
|
Denis Oliver Kropp wrote: > Hi, > > I want to begin with the seperation of the drivers from > MiniGLX by putting a generic layer between them. The goal > is to be able to build the libGL without MiniGLX at all. > > The drivers in src/drv should not know about MiniGLXDisplayRec, > they are currently using the following members: > > dok@skunk[~/cvs/Mesa/src/drv] cgrep 'dpy->' | perl -p -i -e 's/.*(dpy\-\>[\w\.]+).*/\1/g' | sort -u > dpy->bpp > dpy->chipset > dpy->cpp > dpy->driverClientMsg > dpy->driverClientMsgSize > dpy->driverInfo > dpy->drmFD > dpy->FixedInfo.mmio_len > dpy->FixedInfo.mmio_start > dpy->FixedInfo.smem_len > dpy->FixedInfo.smem_start > dpy->FrameBuffer > dpy->IsClient > dpy->MMIOAddress > dpy->pciBus > dpy->pciBusID > dpy->pciChipType > dpy->pciDevice > dpy->pciFunc > dpy->pciVendor > dpy->pSAREA > dpy->shared.fbSize > dpy->shared.hFrameBuffer > dpy->shared.hSAREA > dpy->shared.SAREASize > dpy->shared.virtualHeight > dpy->shared.virtualWidth > dpy->TheWindow > > As a starting point I would like to put these members into a generic > structure and pass it to the drivers. This should have no impact on > the current implementation and is a step forward to the proposed tree > reorganization. What do you think? > > Further steps are a bit more complicated, dpy->TheWindow is still MiniGLX > specific (MiniGLXWindowRec) and that in turn requires more X11 style stuff > like visuals etc. But as far as I've looked through the drivers they only > need "TheWindow" in the vt switching callback. what about a dpy->switch_vt(dpy, ...) callback as member of your generic struct? Holger |
From: Denis O. K. <do...@di...> - 2003-04-25 11:34:10
|
Quoting Holger Waechtler (ho...@co...): > >Further steps are a bit more complicated, dpy->TheWindow is still MiniGLX > >specific (MiniGLXWindowRec) and that in turn requires more X11 style stuff > >like visuals etc. But as far as I've looked through the drivers they only > >need "TheWindow" in the vt switching callback. > > what about a dpy->switch_vt(dpy, ...) callback as member of your generic > struct? I would rather rename the VTSwitchHandler to something more general that is better describing of what is really happening, e.g. Suspend / Resume. So MiniGLX should not call VTSwitchHandler(have_vt), but call Suspend or Resume depending on have_vt. The driver should not know about VTs. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH |
From: Holger W. <ho...@co...> - 2003-04-25 11:44:44
|
Denis Oliver Kropp wrote: > Quoting Holger Waechtler (ho...@co...): > >>>Further steps are a bit more complicated, dpy->TheWindow is still MiniGLX >>>specific (MiniGLXWindowRec) and that in turn requires more X11 style stuff >>>like visuals etc. But as far as I've looked through the drivers they only >>>need "TheWindow" in the vt switching callback. >> >>what about a dpy->switch_vt(dpy, ...) callback as member of your generic >>struct? > > > I would rather rename the VTSwitchHandler to something more general that is > better describing of what is really happening, e.g. Suspend / Resume. > > So MiniGLX should not call VTSwitchHandler(have_vt), but call Suspend or > Resume depending on have_vt. The driver should not know about VTs. :) better. Holger |
From: Jon S. <jon...@ya...> - 2003-04-25 15:10:19
|
--- Denis Oliver Kropp <do...@di...> wrote: > So MiniGLX should not call VTSwitchHandler(have_vt), > but call Suspend or > Resume depending on have_vt. The driver should not > know about VTs. I agree with the driver not knowing about VTs. I'm working on the embedded code in a two video card/monitor/mouse/keyboard system. My boot display has a VT and runs X and the debugger. I run embedded on the secondary display/input. Both displays can't have a VT if you want to simultaneously use the input devices for debugging. I made this work by disabling the VT code in embedded Mesa and added my own input drivers. For my windowing system I'm modifying gpl-embedded-qt to use embedded Mesa as it's base display device. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
From: Denis O. K. <do...@di...> - 2003-04-25 17:07:00
|
Quoting Jon Smirl (jon...@ya...): > For my windowing system I'm modifying gpl-embedded-qt > to use embedded Mesa as it's base display device. I guess you are not using a gl buffer per window but always drawing to the screen directly, are you? -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH |
From: Jon S. <jon...@ya...> - 2003-04-25 17:22:56
|
--- Denis Oliver Kropp <do...@di...> wrote: > I guess you are not using a gl buffer per window but > always drawing to the screen directly, are you? The plan is to use a pbuffer mechanism where windows are drawn to offscreen video memory. The widow manager then composites these onto the visible screen. Check the mesa3d archives, there is a big thread (OpenGL GUI) discussing how to do this. But first I need to finish working the problems out of my input event code. I'm using a single process as a development platform while debugging this. Keith was also implementing some Mesa locking support with appears to be finished now. Another part of the plan is to optionally achieve X compatibility on a per window basis while using the QT code for the window manager and event pump. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
From: Denis O. K. <do...@di...> - 2003-04-25 17:31:05
|
Quoting Jon Smirl (jon...@ya...): > --- Denis Oliver Kropp <do...@di...> wrote: > > I guess you are not using a gl buffer per window but > > always drawing to the screen directly, are you? > > The plan is to use a pbuffer mechanism where windows > are drawn to offscreen video memory. The widow manager > then composites these onto the visible screen. Check > the mesa3d archives, there is a big thread (OpenGL > GUI) discussing how to do this. > > But first I need to finish working the problems out of > my input event code. I'm using a single process as a > development platform while debugging this. Keith was > also implementing some Mesa locking support with > appears to be finished now. > > Another part of the plan is to optionally achieve X > compatibility on a per window basis while using the QT > code for the window manager and event pump. DirectFB windows also have an offscreen buffer and the window stack is composed if windows updated their content. It's limited to 2D but very fast. Within these windows I want to add support for hardware accelerated OpenGL. Of course, DirectFB fullscreen apps can also use it then. If you are not going to have a three dimensional windowing system you could port QT to DirectFB and already have X compatibility via XDirectFB. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH |
From: Jon S. <jon...@ya...> - 2003-04-25 18:31:25
|
--- Denis Oliver Kropp <do...@di...> wrote: > DirectFB windows also have an offscreen buffer and > the window > stack is composed if windows updated their content. > It's limited > to 2D but very fast. Within these windows I want to > add support > for hardware accelerated OpenGL. Of course, DirectFB > fullscreen > apps can also use it then. If you are not going to > have a three > dimensional windowing system you could port QT to > DirectFB and > already have X compatibility via XDirectFB. My goal is to used embedded Mesa (OpenGL) as the base hardware portability layer. There is no 2D API other than the one inside of OpenGL. This is an experiment to see if OpenGL can work as the base graphics interface for building a GUI. If it does, then closed source vendors could just release binary OpenGL implementations and the rest of the GUI would load on top. 2D cards can work in the same framework by using software Mesa to implement their OpenGL driver. The QT windowing system is tiny compared to X making it much easier to work with. This is still a "direct" display system. Each process directly manipulates the video hardware to draw it's non-visible window (with DRM assist). The window manager process them composites (transparency, 3D transform, etc) these windows to build the visible screen. Remote access is done via a server process that listens to the network. It then uses the direct API to draw window contents. This server process will talk X Protocol but nothing has been written yet. I believe this process is similar to what XDirectFB does, right? ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
From: Keith W. <ke...@tu...> - 2003-04-25 18:36:54
|
Jon Smirl wrote: > --- Denis Oliver Kropp <do...@di...> wrote: > >>DirectFB windows also have an offscreen buffer and >>the window >>stack is composed if windows updated their content. >>It's limited >>to 2D but very fast. Within these windows I want to >>add support >>for hardware accelerated OpenGL. Of course, DirectFB >>fullscreen >>apps can also use it then. If you are not going to >>have a three >>dimensional windowing system you could port QT to >>DirectFB and >>already have X compatibility via XDirectFB. > > > My goal is to used embedded Mesa (OpenGL) as the base > hardware portability layer. There is no 2D API other > than the one inside of OpenGL. > > This is an experiment to see if OpenGL can work as the > base graphics interface for building a GUI. If it > does, then closed source vendors could just release > binary OpenGL implementations and the rest of the GUI > would load on top. 2D cards can work in the same > framework by using software Mesa to implement their > OpenGL driver. > > The QT windowing system is tiny compared to X making > it much easier to work with. This is still a "direct" > display system. Each process directly manipulates the > video hardware to draw it's non-visible window (with > DRM assist). The window manager process them > composites (transparency, 3D transform, etc) these > windows to build the visible screen. How well does the "server" process stuff I've done over the last week or two map into your ideas of a window manager process? Or are they disjoint ideas? Keith |
From: Jon S. <jon...@ya...> - 2003-04-25 18:54:26
|
--- Keith Whitwell <ke...@tu...> wrote: > How well does the "server" process stuff I've done > over the last week or two > map into your ideas of a window manager process? Or > are they disjoint ideas? > They could be made to be the same. I just brought down your new miniglx code in the last couple of days and I haven't been able to figure out why I can't draw any more. I can erase the background but no drawing is visible. Do I need to do something special to be able to draw from the server process? I tried merging __miniglx_StartServer() and XOpenDisplay() back into a single function. Have you looked at using the window manager out of embedded QT? It is GPL code. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
From: Denis O. K. <do...@di...> - 2003-04-25 19:08:47
|
Quoting Jon Smirl (jon...@ya...): > --- Keith Whitwell <ke...@tu...> wrote: > > How well does the "server" process stuff I've done > > over the last week or two > > map into your ideas of a window manager process? Or > > are they disjoint ideas? > > > They could be made to be the same. I just brought down > your new miniglx code in the last couple of days and I > haven't been able to figure out why I can't draw any > more. I can erase the background but no drawing is > visible. Maybe you miss the same XNextEvent() loop that I added to glxgears in one of my last patches. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH |
From: Keith W. <ke...@tu...> - 2003-04-25 20:04:24
|
Jon Smirl wrote: > --- Keith Whitwell <ke...@tu...> wrote: > >>How well does the "server" process stuff I've done >>over the last week or two >>map into your ideas of a window manager process? Or >>are they disjoint ideas? >> > > They could be made to be the same. I just brought down > your new miniglx code in the last couple of days and I > haven't been able to figure out why I can't draw any > more. I can erase the background but no drawing is > visible. > > Do I need to do something special to be able to draw > from the server process? I tried merging > __miniglx_StartServer() and XOpenDisplay() back into a > single function. This is broken at the moment, but I want to fix it. Currently there are assumptions being made that limit drawing to the clients. > Have you looked at using the window manager out of > embedded QT? It is GPL code. Hmm I'll have a look. Is there an easy url? Keith |
From: Denis O. K. <do...@di...> - 2003-04-25 18:59:57
|
Quoting Jon Smirl (jon...@ya...): > --- Denis Oliver Kropp <do...@di...> wrote: > > DirectFB windows also have an offscreen buffer and > > the window > > stack is composed if windows updated their content. > > It's limited > > to 2D but very fast. Within these windows I want to > > add support > > for hardware accelerated OpenGL. Of course, DirectFB > > fullscreen > > apps can also use it then. If you are not going to > > have a three > > dimensional windowing system you could port QT to > > DirectFB and > > already have X compatibility via XDirectFB. > > My goal is to used embedded Mesa (OpenGL) as the base > hardware portability layer. There is no 2D API other > than the one inside of OpenGL. > > This is an experiment to see if OpenGL can work as the > base graphics interface for building a GUI. If it > does, then closed source vendors could just release > binary OpenGL implementations and the rest of the GUI > would load on top. 2D cards can work in the same > framework by using software Mesa to implement their > OpenGL driver. > > The QT windowing system is tiny compared to X making > it much easier to work with. This is still a "direct" > display system. Each process directly manipulates the > video hardware to draw it's non-visible window (with > DRM assist). The window manager process them > composites (transparency, 3D transform, etc) these > windows to build the visible screen. > > Remote access is done via a server process that > listens to the network. It then uses the direct API to > draw window contents. This server process will talk X > Protocol but nothing has been written yet. I believe > this process is similar to what XDirectFB does, right? Yes, XDirectFB is a rootless X server on top of DirectFB. It's based on XDarwin because DirectFB can be compared to Cocoa. You may have a look at our web site where you can find several screenshots of the multi application core showing X applications and native DirectFB applications running side by side (actually transparent on top of each other). DirectFB does all the input and focus handling etc. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH |