Re: DRM Modesetting fbset tool?
On Tuesday 29 April 2008 17:29:24 Jerome Glisse wrote: For console we had the idea of building a full userspace console things instead of having this whole things in the kernel. Which would mean to write some userspace program using the modesetting API and providing the console. I believe there is several advantages (i talk about drawbacks latter) for instance you can do a fency console, or have multiple console at the same time by dividing screen, or have efficient multi-seat console with nice screen input association. Well many things worth having for the XXI century where car flies and robots wash the house and do the laundry. I'm not sure I quite follow on the user-space console thing. Do you mean that tty0-5 get removed replaced with ptys? In fact the only real ttys left are serial ports? A daemon process is created by init which opens the drm input devices, creates 6 or so ptys for each vt. It then implements a framebuffer vt102 or something and lets init attach gettys or whatever to the slave ptys. The daemon watches for Alt+Fx etc. and switches framebuffers which pty it sends keyboard input to. Have I understood correctly? It seems like vt's become a completely user-space thing. This is great for console applications, but what about graphics applications? Is that where this multi-master thing comes in to play? Main drawback i see, is for rescue case, ie we likely need to keep a minimal console in kernel as in rescue we can't rely on userspace to be their or operational. Their is likely others drawback but none of importance come to my mind. There's also the boot splash before the kernel brings up userspace (although I think userspace is brought up pretty quickly with initramfs). There's also all the fbdev drivers, although I guess the user-space console could also support the fbdev interface too. Anyway i believe such things need to be discused on lkml but as the API and things like multi-master, DRM2, ... are not yet worked out i believe its a bit too early to bring this topic on lkml (given that this might proove to lead to some nice flamewar :() Still you might be interested in writing a proof of concept user space console. Adapting it to API change won't be that hard. Yeah, you seem to be talking about some fairly major changes to Linux. Where is all this discussion going on? Is there a DRI2 mailing list somewhere? I'd quite like to follow what's being planned. As for userspace console, it seems fairly strait forward. I guess the easiest thing would be to grab an existing terminal emulator which renders to a framebuffer adapt it? Either fbcon or something like rxvt/similar. Thanks for the info! Cheers, Tom - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15739] [915]mesa xdemo 'manywin' run abort
http://bugs.freedesktop.org/show_bug.cgi?id=15739 Colin.Joe [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Colin.Joe [EMAIL PROTECTED] 2008-04-30 02:17:32 PST --- There are 2 commit which interval is the shortest: . commit 33107357a1226b9218fac410a7502a981aac5cc5 commit 711222bb7b4fd7ea8e7f801ac26532360bc5440f The preceding one can reproduce this bug, and the latter one runs fine . So the commit 33107357a1226b9218fac410a7502a981aac5cc5 makes this issue . -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM Modesetting fbset tool?
On Wednesday 30 April 2008 10:59:03 Jerome Glisse wrote: For console we had the idea of building a full userspace console things instead of having this whole things in the kernel. Which would mean to write some userspace program using the modesetting API and providing the console. I believe there is several advantages (i talk about drawbacks latter) for instance you can do a fency console, or have multiple console at the same time by dividing screen, or have efficient multi-seat console with nice screen input association. Well many things worth having for the XXI century where car flies and robots wash the house and do the laundry. I'm not sure I quite follow on the user-space console thing. Do you mean that tty0-5 get removed replaced with ptys? In fact the only real ttys left are serial ports? A daemon process is created by init which opens the drm input devices, creates 6 or so ptys for each vt. It then implements a framebuffer vt102 or something and lets init attach gettys or whatever to the slave ptys. The daemon watches for Alt+Fx etc. and switches framebuffers which pty it sends keyboard input to. Have I understood correctly? It seems like vt's become a completely user-space thing. This is great for console applications, but what about graphics applications? Is that where this multi-master thing comes in to play? Graphic applications like X are just another client and handled the same way. Some master will be in charge to switch btw terminal and X or others client. What i mean is that the console is a program in itself, different from the master and a client of it. Ok... I think I see what you're getting at... So init launches this all-powerful master process as root, then launches 6 console processes, (one for each virtual console) as a non-root user. Each console process connects to the master (using sockets? DBus?), some authentication goes on to make sure they're allowed to access the DRM. The console process then opens the DRM, sets up a BO for the scan-out buffer creates a psudo-terminal pair, with the slave end dangling ready to be attached to getty. The all-powerful master tells the console process it is now the current vt and can attach its scan-out buffer(s) to any crtc it is allowed to. When the user initiates a vt-switch, the master tells the console it is no-longer the current vt and should detach it's scanout buffer so the new current slave can attach it's scan-out buffer instead. Main drawback i see, is for rescue case, ie we likely need to keep a minimal console in kernel as in rescue we can't rely on userspace to be their or operational. Their is likely others drawback but none of importance come to my mind. There's also the boot splash before the kernel brings up userspace (although I think userspace is brought up pretty quickly with initramfs). There's also all the fbdev drivers, although I guess the user-space console could also support the fbdev interface too. fbdev driver of drm supported card will be removed. Likely only keep a fbdev emulation layer in drm but i guess we highly prefer native drm user than one using such emulation layer. I'm just thinking about how this is going to work on non-DRM graphics devices, where the driver is fbdev, DirectFB, proprietry, etc. Of course if there's a DRM driver, the DRM modesetting API sould be used. But the fbdev driver could potentially be used if DRM is unavaliable. In a perfect world, there would only be DRM. Actually I'm thinking about taking a look at writing a drm modesetting driver for very stupid hardware like an OMAP3 LCD controller. Everything, including the framebuffer BOs would be stored in main memory as that's all these devices have! Could then look at how to handle video decoded by the OMAP's DSP in a DRM-friendly way. Cheers, Tom - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM Modesetting fbset tool?
On Wed, 30 Apr 2008 09:43:31 +0200 Tom Cooksey [EMAIL PROTECTED] wrote: On Tuesday 29 April 2008 17:29:24 Jerome Glisse wrote: For console we had the idea of building a full userspace console things instead of having this whole things in the kernel. Which would mean to write some userspace program using the modesetting API and providing the console. I believe there is several advantages (i talk about drawbacks latter) for instance you can do a fency console, or have multiple console at the same time by dividing screen, or have efficient multi-seat console with nice screen input association. Well many things worth having for the XXI century where car flies and robots wash the house and do the laundry. I'm not sure I quite follow on the user-space console thing. Do you mean that tty0-5 get removed replaced with ptys? In fact the only real ttys left are serial ports? A daemon process is created by init which opens the drm input devices, creates 6 or so ptys for each vt. It then implements a framebuffer vt102 or something and lets init attach gettys or whatever to the slave ptys. The daemon watches for Alt+Fx etc. and switches framebuffers which pty it sends keyboard input to. Have I understood correctly? It seems like vt's become a completely user-space thing. This is great for console applications, but what about graphics applications? Is that where this multi-master thing comes in to play? Graphic applications like X are just another client and handled the same way. Some master will be in charge to switch btw terminal and X or others client. What i mean is that the console is a program in itself, different from the master and a client of it. Main drawback i see, is for rescue case, ie we likely need to keep a minimal console in kernel as in rescue we can't rely on userspace to be their or operational. Their is likely others drawback but none of importance come to my mind. There's also the boot splash before the kernel brings up userspace (although I think userspace is brought up pretty quickly with initramfs). There's also all the fbdev drivers, although I guess the user-space console could also support the fbdev interface too. fbdev driver of drm supported card will be removed. Likely only keep a fbdev emulation layer in drm but i guess we highly prefer native drm user than one using such emulation layer. Anyway i believe such things need to be discused on lkml but as the API and things like multi-master, DRM2, ... are not yet worked out i believe its a bit too early to bring this topic on lkml (given that this might proove to lead to some nice flamewar :() Still you might be interested in writing a proof of concept user space console. Adapting it to API change won't be that hard. Yeah, you seem to be talking about some fairly major changes to Linux. Where is all this discussion going on? Is there a DRI2 mailing list somewhere? I'd quite like to follow what's being planned. I guess this are discussed on IRC but i think now most people are pretty agree with broadline of redesign. http://dri.freedesktop.org/wiki/DRMRedesign As for userspace console, it seems fairly strait forward. I guess the easiest thing would be to grab an existing terminal emulator which renders to a framebuffer adapt it? Either fbcon or something like rxvt/similar. Yes, i am confident that there is many code on which to build such things. Doing the drm kernel side is more cumberstone. Cheers, Jerome Glisse [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15191] [965]mesa xdemo 'manywin' run abort
http://bugs.freedesktop.org/show_bug.cgi?id=15191 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Eric Anholt [EMAIL PROTECTED] 2008-04-30 11:06:27 PST --- *** This bug has been marked as a duplicate of bug 13890 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15717] [965]mesa xdemo 'manywin' crash X
http://bugs.freedesktop.org/show_bug.cgi?id=15717 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Eric Anholt [EMAIL PROTECTED] 2008-04-30 11:07:15 PST --- *** This bug has been marked as a duplicate of bug 13890 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15191] [965]mesa xdemo 'manywin' run abort
http://bugs.freedesktop.org/show_bug.cgi?id=15191 Bug 15191 depends on bug 15717, which changed state. Bug 15717 Summary: [965]mesa xdemo 'manywin' crash X http://bugs.freedesktop.org/show_bug.cgi?id=15717 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15739] [915]mesa xdemo 'manywin' run abort
http://bugs.freedesktop.org/show_bug.cgi?id=15739 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Eric Anholt [EMAIL PROTECTED] 2008-04-30 11:07:56 PST --- *** This bug has been marked as a duplicate of bug 13890 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel TTM superioctl / execbuf deadlock.
Eric Anholt wrote: On Thu, 2008-04-24 at 11:30 +0200, Thomas Hellström wrote: There is a possibility of a deadlock in the current Intel superioctl path, which can be illustrated by two contexts rendering simultaneously from the same textures, One context using fallback rendering, the other using the GPU. Context 1 will start mapping the texture buffers, Context 2 will take the cmdbuf mutex and start validating the same texture buffers. Now if they end up having the buffer lists reversed, context 1 might end up waiting to map a buffer that context2 has validated for the GPU, while context2 will wait for a buffer that context1 has mapped = deadlock. One way around this is to use the hardware lock around all buffer mapping (including client buffer object mapping) and command submission, I believe the old i915tex driver did this to a large extent. I'm not sure what the current i915 driver does. Anyway, we need a more fine-grained approach. In master we hold the lock around execbuffer. Is getting multiple cpus in the validate path a bottleneck, really, where a finer-grained approach is needed? I think in most of the cases we're dealing with today, a single thread in the execbuf path is sufficient. However, I think if you use the HW lock to resolve this deadlock you'll also need the hw lock around all code paths where you have multiple buffers mapped simultaneously. Since mapping may require a (possibly lengthy) wait for idle, one needs to be careful to try to idle all buffers before taking the hardware lock. Anyway, regardless whether we can work around this using the hardware lock in current drivers, I think a more general solution would need to allow multiple threads into the validate path, and also allowing lock-free operation where possible. It's a problem that isn't too hard to solve. /Thomas - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2913] kernel oops on modules unload
http://bugzilla.kernel.org/show_bug.cgi?id=2913 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] ||bugs.osdl.org Status|ASSIGNED|NEW -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel TTM superioctl / execbuf deadlock.
On Thu, 2008-04-24 at 11:30 +0200, Thomas Hellström wrote: There is a possibility of a deadlock in the current Intel superioctl path, which can be illustrated by two contexts rendering simultaneously from the same textures, One context using fallback rendering, the other using the GPU. Context 1 will start mapping the texture buffers, Context 2 will take the cmdbuf mutex and start validating the same texture buffers. Now if they end up having the buffer lists reversed, context 1 might end up waiting to map a buffer that context2 has validated for the GPU, while context2 will wait for a buffer that context1 has mapped = deadlock. One way around this is to use the hardware lock around all buffer mapping (including client buffer object mapping) and command submission, I believe the old i915tex driver did this to a large extent. I'm not sure what the current i915 driver does. Anyway, we need a more fine-grained approach. In master we hold the lock around execbuffer. Is getting multiple cpus in the validate path a bottleneck, really, where a finer-grained approach is needed? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7155] Mach64 machine freeze with anything but glxgears
http://bugs.freedesktop.org/show_bug.cgi?id=7155 --- Comment #1 from mitch074 [EMAIL PROTECTED] 2008-04-30 13:51:44 PST --- Pinging this bug, I have similar hardware IBM Thinkpad with Rage Mobility M1/8Mb (AGP, mach64 core with texel unit); symptoms remain with latest 6.8.0 ati driver, and recent-ish DRM CVS extract, on Ubuntu 7.10 X server (version 1.3.1 if I'm not mistaken). Basically, as soon as textures are sent to the chip in a 3D context, the system locks hard (sysrq doesn't work either). I managed, only once, to get a correctly rendered Google Earth's first frame (and I could see it once the machine was frozen), so 3D code may still work and the bug could be trivial, but for now it completely blocks 3D on mach64. Could we at least have a status report, as in, bug will be fixed once the TTM is finalized and mach64 makes use of it? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel TTM superioctl / execbuf deadlock.
On Wed, Apr 30, 2008 at 2:53 PM, Thomas Hellström [EMAIL PROTECTED] wrote: Anyway, regardless whether we can work around this using the hardware lock in current drivers, I think a more general solution would need to allow multiple threads into the validate path, and also allowing lock-free operation where possible. It's a problem that isn't too hard to solve. I agree, it should definitely be doable. Kristian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
