Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
The fb_ops can only be called from fbcon or the fbdev userland interface. The fbcon calls should only happen when the VC is in KD_TEXT mode. Now with the DRM backend we have the advantage of creating a mapping seperate from the console mapping. A fb_open/fb_close could be used to cleaning up the userland mmap as well as handle the console pinning. We can supply your own fb_mmap hook. Again, the issue is not userspace but that fb_ops hooks can be called from interrupt context etc. This should not happen. The VT layer is protected from calling in the interrupt context. TNor does fbcon call any fb_ops methods from a irq. E.g. printk? Sorry I have been sick. This is true when you are in KD_TEXT mode and using fbcon. Now while working on a graphical console yes you can have other hardware devices do a printk which can alter the state of of your graphics card. As for debugging a graphics driver you have to be very careful with your printks. Usually in that case I use two graphics cards in my system and map one to fbcon and test the other graphcis cards driver. P.S The fbdev api is such that it doesn't always require a permanent framebuffer mapping. This was done for the case of graphical hardware that lacks a directly accessable framebuffer. If you have accelerated fillrect,copyarea,and imageblit then you don't even the mapping except in the case of someone calling mmap on /dev/fbX. I noticed the nouveau drivers has a accelerated fbcon :-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
The fb_ops can only be called from fbcon or the fbdev userland interface. The fbcon calls should only happen when the VC is in KD_TEXT mode. Now with the DRM backend we have the advantage of creating a mapping seperate from the console mapping. A fb_open/fb_close could be used to cleaning up the userland mmap as well as handle the console pinning. We can supply your own fb_mmap hook. Again, the issue is not userspace but that fb_ops hooks can be called from interrupt context etc. This should not happen. The VT layer is protected from calling in the interrupt context. TNor does fbcon call any fb_ops methods from a irq. I have to look at the fbdev drivers but to my knowledge none touch any memory while in a context. Have you seen this happen before? Please let me know do I can fix it right a way. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Tue, 2010-03-16 at 13:56 +, James Simmons wrote: The fb_ops can only be called from fbcon or the fbdev userland interface. The fbcon calls should only happen when the VC is in KD_TEXT mode. Now with the DRM backend we have the advantage of creating a mapping seperate from the console mapping. A fb_open/fb_close could be used to cleaning up the userland mmap as well as handle the console pinning. We can supply your own fb_mmap hook. Again, the issue is not userspace but that fb_ops hooks can be called from interrupt context etc. This should not happen. The VT layer is protected from calling in the interrupt context. TNor does fbcon call any fb_ops methods from a irq. E.g. printk? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Searching the TTM code I couldn't find the handle code so easily. I see that the vmwgfx driver provides a example of using ttm. So handles are purely a userspace interface, in-kernel we don't use handles for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle to do the bo lookups. Yeap, some how userland has to tell which buffer is which. I also noticed their is a ttm_base_object_lookup which does the same thing :-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
The big issue we have with resizing the buffer is userspace mmaps of the fbdev device, and invalidation. Previous thread of unresolvedness is here. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html Actually AFAIR (and reading through it again seems to confirm this) userspace mappings should be fully handled by the last patch series I posted back then[0]. The problem was that the struct fb_ops hooks may be called by the kernel from pretty much any context, and neither I nor Thomas was sure how to handle the TTM locking given that. Maybe James has ideas for this given his better familiarity with fbdev internals. The fb_ops can only be called from fbcon or the fbdev userland interface. The fbcon calls should only happen when the VC is in KD_TEXT mode. Now with the DRM backend we have the advantage of creating a mapping seperate from the console mapping. A fb_open/fb_close could be used to cleaning up the userland mmap as well as handle the console pinning. We can supply your own fb_mmap hook. [0] Though that was really only about making it possible to unpin the fbcon BO while it isn't being displayed, resizing it might involve other issues I'm not aware of. Yeap, but both problems are related. Kill two birds with one stone. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Sun, 2010-03-14 at 07:01 +1000, Dave Airlie wrote: The big issue we have with resizing the buffer is userspace mmaps of the fbdev device, and invalidation. Previous thread of unresolvedness is here. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html Actually AFAIR (and reading through it again seems to confirm this) userspace mappings should be fully handled by the last patch series I posted back then[0]. The problem was that the struct fb_ops hooks may be called by the kernel from pretty much any context, and neither I nor Thomas was sure how to handle the TTM locking given that. Maybe James has ideas for this given his better familiarity with fbdev internals. [0] Though that was really only about making it possible to unpin the fbcon BO while it isn't being displayed, resizing it might involve other issues I'm not aware of. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Can't it print the oops on whatever is currently displayed? It need not be a dedicated buffer as long as there is always some buffer. But perhaps this is more complex than that. Yes it is very complex. Reading the code and drm specs you come to realize buffer handling is done with GEM, TTM, or for older drivers drm_maps. Drivers often handle a combine of those, meaning no real wrapper from one api to another :-( From the code it appears GEM is the main userland interface when using KMS. Some how TTM is also usable from userland but I never found a clear example of how that is done. So to the average userland app writer it is a mystery. As for hardware that has a static front buffer I can see how to use drm_maps or TTM but I don't see a easy way to map it to the GEM api. Also their exist ioctl for gem but it appears no one actually uses them but instead write their own :-( So you can see the confusion here. Userspace buffer management interfaces are pre-driver, the only requirement if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers don't exist for the purposes of fb interaction, so drm_maps are ignorable from that pov. Outside of what I described above the drm_framebuffer handling is a mess. From what I can see with the code you can only create a drm_framebuffer with the GEM api. With this case the two most important functions to provide are This isn't correct. You get a drm_file and a handle, the driver then uses these to do whatever it wants to do. This means lookup a GEM object or whatever but there is no reliance on GEM or any other memory manager outside the driver. Again a handle a file priv are in no way GEM specific. Searching the TTM code I couldn't find the handle code so easily. I see that the vmwgfx driver provides a example of using ttm. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done. I'm not sure either of these makes sense, can you clearly state the goal and maybe we can work out what you need. Sorry I should of stated what I was planing to do. I like to see drmfb have the ablitiy to change the resolution via fbset. To do that we need to be able to create and destory the framebuffer memory if the memory doesn't fit the size of the new resolution. Plus it gives us the bonus of being able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem is that the functions like fb_create are tied to a handle which is not present for the internal framebuffer used by fbdev. Sorry for the junk above. It just took me awhile to figure out the code. Their is steep learning curve. I have patches that should address this coming soon. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Searching the TTM code I couldn't find the handle code so easily. I see that the vmwgfx driver provides a example of using ttm. So handles are purely a userspace interface, in-kernel we don't use handles for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle to do the bo lookups. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done. I'm not sure either of these makes sense, can you clearly state the goal and maybe we can work out what you need. Sorry I should of stated what I was planing to do. I like to see drmfb have the ablitiy to change the resolution via fbset. To do that we need to be able to create and destory the framebuffer memory if the memory doesn't fit the size of the new resolution. Plus it gives us the bonus of being able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem is that the functions like fb_create are tied to a handle which is not present for the internal framebuffer used by fbdev. Sorry for the junk above. It just took me awhile to figure out the code. Their is steep learning curve. I have patches that should address this coming soon. Okay first up, there are two sets of codepaths, please ignore vmwgfx for now, its _fb implementation is not yet using the drm_fb_helper.c code and it needs to be converted if possible. Originally all the drivers had their own fb code, but its was mostly pointless, the helper allows for drivers to optionally use the shared code, ideally we'd like all drivers to use that code so we get consistent operation across drivers, so user experience isn't driver dependent unless unavoidable. The big issue we have with resizing the buffer is userspace mmaps of the fbdev device, and invalidation. Previous thread of unresolvedness is here. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html If you look at the current fb code, when we get a hotplug event in theory, we try and reuse the current framebuffer. I suppose initially it would be worth trying the resize downwards and keep the current fbdev, but the whole mmap area was the cause of most of the problems and it seemed like a real pain to fix. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Thu, 11 Mar 2010, Michal Suchanek wrote: On 11 March 2010 16:17, James Simmons jsimm...@infradead.org wrote: It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. I'm all for it! I'm looking into the details for this. It will require some changes to internal apis to make it to work. Can't it print the oops on whatever is currently displayed? It need not be a dedicated buffer as long as there is always some buffer. But perhaps this is more complex than that. Yes it is very complex. Reading the code and drm specs you come to realize buffer handling is done with GEM, TTM, or for older drivers drm_maps. Drivers often handle a combine of those, meaning no real wrapper from one api to another :-( From the code it appears GEM is the main userland interface when using KMS. Some how TTM is also usable from userland but I never found a clear example of how that is done. So to the average userland app writer it is a mystery. As for hardware that has a static front buffer I can see how to use drm_maps or TTM but I don't see a easy way to map it to the GEM api. Also their exist ioctl for gem but it appears no one actually uses them but instead write their own :-( So you can see the confusion here. Outside of what I described above the drm_framebuffer handling is a mess. From what I can see with the code you can only create a drm_framebuffer with the GEM api. With this case the two most important functions to provide are dev-mode_config.funcs-fb_create(dev, file_priv, r) and fb-funcs-create_handle(fb, file_priv, r-handle); As you can see if the functions they depend on a handle and a drm_file. To make it possible to create a framebuffer internally using a common code we would remove those requirements. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done.-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. I'm all for it! I'm looking into the details for this. It will require some changes to internal apis to make it to work. Can't it print the oops on whatever is currently displayed? It need not be a dedicated buffer as long as there is always some buffer. But perhaps this is more complex than that. Yes it is very complex. Reading the code and drm specs you come to realize buffer handling is done with GEM, TTM, or for older drivers drm_maps. Drivers often handle a combine of those, meaning no real wrapper from one api to another :-( From the code it appears GEM is the main userland interface when using KMS. Some how TTM is also usable from userland but I never found a clear example of how that is done. So to the average userland app writer it is a mystery. As for hardware that has a static front buffer I can see how to use drm_maps or TTM but I don't see a easy way to map it to the GEM api. Also their exist ioctl for gem but it appears no one actually uses them but instead write their own :-( So you can see the confusion here. Userspace buffer management interfaces are pre-driver, the only requirement if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers don't exist for the purposes of fb interaction, so drm_maps are ignorable from that pov. Outside of what I described above the drm_framebuffer handling is a mess. From what I can see with the code you can only create a drm_framebuffer with the GEM api. With this case the two most important functions to provide are This isn't correct. You get a drm_file and a handle, the driver then uses these to do whatever it wants to do. This means lookup a GEM object or whatever but there is no reliance on GEM or any other memory manager outside the driver. Again a handle a file priv are in no way GEM specific. dev-mode_config.funcs-fb_create(dev, file_priv, r) and fb-funcs-create_handle(fb, file_priv, r-handle); As you can see if the functions they depend on a handle and a drm_file. To make it possible to create a framebuffer internally using a common code we would remove those requirements. We already have an internal framebuffer creation for fbdev, there is an fb_create callback that does this, its not up to dynamic fbdev creation. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done. I'm not sure either of these makes sense, can you clearly state the goal and maybe we can work out what you need. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 10 March 2010 22:04, Ville Syrjälä syrj...@sci.fi wrote: On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote: I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. Only because that is the only way to do it. The other options was to have x86emul in the kernel. That was not going to happen. I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. Still would have to deal with the issue of keeping the graphical console in sync with the changes. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. omapfb is another multihead fb driver and it's more complex than matroxfb. Trying to make it perform various tricks through the fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs) is something I've been doing but I would not recommend it for anyone who has the option of using a better API. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. I guess it's also possible that somebody would want the fbdev/fbcons cover multiple screens. This is not particularly useful with fbcons (although curses WMs exist) but might be somewhat useful for graphical fbdev applications. Multiple views of the kernel virtual consoles on different heads might be nice toy but it's probably too hard to be worth trying. And there are always applications like jfbterm which could be perhaps slightly adapted to use one of the other devices instead of a vc. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 10 March 2010 19:47, James Simmons jsimm...@infradead.org wrote: Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Ah, the power of flags. We had the same issue with user requesting a mode change or fbcon asking for a different mode. We handled it with the flag FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will have to deal also with the ability to change the resolution with tools like stty. I can easily see how to do this plus give you more memory like you want :-) For the oops are you talking about printing oops to the screen while X is running ? Otherwise if you experience a oops and go back to console mode you should be able to view it. The console text buffer is independent of the graphics card memory system. Ability to print the oops over X does not seem to be that bad idea. Since with KMS the kernel finally knows what X is doing with the graphics it should be able to print it. Note that it may be the only way to see it in situations when the console dies in one way or another. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 10 March 2010 18:42, James Simmons jsimm...@infradead.org wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. So you get the layering naturally. On fbset - fbev layer you can choose from the resolutions available in the current output setup, in kmset or whatever - drm layer you can set up the outputs, merge multiple outputs into single cloned fbdev or separate them, .. It's obviously nice if you can set the resolution on all of fbcons, fbdev and drm layers but getting it work on at least one layer with proper propagation up and down also works. BTW I don't know any application which sets linux console (or xterm for that matter) resolution through the terminal API. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
2010/3/11 Michel Dänzer mic...@daenzer.net: On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. +1 For me only way to capture oopses is netconsole. But I'm causing all my oopses in radeon/ttm modules. That might prevent the system from returning to framebuffer console. Pinning framebuffer console is only for developers feature so it should be non-default option. For users it is more important to have all VRAM available when required and fully functional console if they use it. In case of kernel oops there should some different way to collect them in users system. They should be stored in hard disk for easier attaching to the bug report. Also oopses that are stored in hd can be later uploaded automatically with kerneloops daemon. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
2010/3/11 Michel Dänzer mic...@daenzer.net: On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. I'm all for it! Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. I'm all for it! I'm looking into the details for this. It will require some changes to internal apis to make it to work. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 11 March 2010 16:17, James Simmons jsimm...@infradead.org wrote: It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. I'm all for it! I'm looking into the details for this. It will require some changes to internal apis to make it to work. Can't it print the oops on whatever is currently displayed? It need not be a dedicated buffer as long as there is always some buffer. But perhaps this is more complex than that. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? Yes it could work. No it doesn't work. Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. Before we go there you have to reflect on what the original reason was to have a framebuffer layer. The point to have a VT console terminal on platforms that lacked hardware that supported native text mode hardware. In other words had no vga text mode. A VT terminal is just a keyboard and a display. In fact in the old days you had to write framebuffer console drivers with things like con_putcs, con_write. Then the api was changed to make driver writing simple. The struct fb_info represented your graphics card. Of course at that time we also had hardware that supported more than one crtc which made things more complex. This was reflected in the new api. Struct fb_info was moved in the direction to represent the display. Remember the terminal only really cares about the display. Inside struct fb_info we have a void *par that was a pointer to some structure that represented the graphics card itself. So in the case of multi-head systems you could have two struct fb_info and one shared *par. That way if you wanted to changed the resolution on one screen the check_var function could using the *par to test if the hardware could support both resolutions at the same time. Note also there is exist a sysfs that allows you to migrate your second fbdev devices to a new terminal. Also problems exist in the upper console layers that prohibit true multi-desktop systems. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
My main problem with calling the drm underneath the fbdev is it seems like a layering violation. Then again some of code in the kernel is also contributing to this violation. I'd really like to make fbdev more like an in-kernel version of what X driver have to do, and leave all the initial modepicking etc to the fbdev interface layer. If we take the layering as fbcon - fbdev - kms - hw I feel calling ioctls on the KMS layer from userspace to do stuff for fbcon or fbdev is wrong, and we should rather expose a more intelligent set of ioctls via the fbdev device node. This points at quite a bit of typing. I agree. We had the same issue with fbdev and fbcon. From the fbcon layer you can call stty to change the resolution. In that case the mode change came from fbcon to fbdev. Easy problem to handle. Well some people still wanted to be able to able to change their console resolution with fbset. Not only change the resolution on one VC (virtual consoel) but in some cases change the resolution on all the VCs mapped to that fbdev. Now some times the user wanted to change the resolution for say a game (using SDL for example) and then expected the fbcon resolution to be restored when they exited. In that case we wanted the resolution change not to be propagated up to the fbcon layer. The way the fbdev changes are propagated with a notifier chain. Now the issue of mirroring is another thing which was never settled on. Considering now the KMS layer is not so bad as it seems. The fbdev emulation layer already changes the drm mode (fbdev - kms) plus in that case you get the benefit of automatically sending a signal to the fbcon layer to keep it in sync. In the case of kms - fbdev you need to update the fbdev state. This could be done pretty easily plus if done right would update the fbcon state as well. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. Only because that is the only way to do it. The other options was to have x86emul in the kernel. That was not going to happen. I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. Still would have to deal with the issue of keeping the graphical console in sync with the changes. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. Designing an unified multihead fbdev extension interface would probably take quite a bit of typing and time. It would also help to have something working to compare to. IMNSHO the fbdev to ctrc mapping should be the standard way to handle the fbdev layer. Plus it is a KISS approach. Mirroring would need to be finally dealt with. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Ah, the power of flags. We had the same issue with user requesting a mode change or fbcon asking for a different mode. We handled it with the flag FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will have to deal also with the ability to change the resolution with tools like stty. I can easily see how to do this plus give you more memory like you want :-) For the oops are you talking about printing oops to the screen while X is running ? Otherwise if you experience a oops and go back to console mode you should be able to view it. The console text buffer is independent of the graphics card memory system. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 1:47 PM, James Simmons jsimm...@infradead.org wrote: Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Ah, the power of flags. We had the same issue with user requesting a mode change or fbcon asking for a different mode. We handled it with the flag FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will have to deal also with the ability to change the resolution with tools like stty. I can easily see how to do this plus give you more memory like you want :-) For the oops are you talking about printing oops to the screen while X is running ? Otherwise if you experience a oops and go back to console mode you should be able to view it. The console text buffer is independent of the graphics card memory system. Right now we keep the console buffer pinned in vram and we switch to it when there is an oops or when you switch VTs. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote: I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. Only because that is the only way to do it. The other options was to have x86emul in the kernel. That was not going to happen. I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. Still would have to deal with the issue of keeping the graphical console in sync with the changes. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. omapfb is another multihead fb driver and it's more complex than matroxfb. Trying to make it perform various tricks through the fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs) is something I've been doing but I would not recommend it for anyone who has the option of using a better API. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. Yes the mapping issue were never address. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. Actually that is what I had in mind when I reworked the fbdev api. Plus with the linux console project I got multiple VTs working at the same time. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. Not true. You can map different displays to different vcs. Give con2fb a try some time :-) Now there is the issue of more than one keyboard being mapped at a time. BTW I did getting multipe VT working at the same time working in the past. It requires some cleanup on the console layer. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. I guess it's also possible that somebody would want the fbdev/fbcons cover multiple screens. This is not particularly useful with fbcons (although curses WMs exist) but might be somewhat useful for graphical fbdev applications. I really can't see fbcon need that. Multiple views of the kernel virtual consoles on different heads might be nice toy but it's probably too hard to be worth trying. And there are always applications like jfbterm which could be perhaps slightly adapted to use one of the other devices instead of a vc. It already exist. I guess it is one of those best kept secrets. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. So you get the layering naturally. On fbset - fbev layer you can choose from the resolutions available in the current output setup, in kmset or whatever - drm layer you can set up the outputs, merge multiple outputs into single cloned fbdev or separate them, .. It's obviously nice if you can set the resolution on all of fbcons, fbdev and drm layers but getting it work on at least one layer with proper propagation up and down also works. BTW I don't know any application which sets linux console (or xterm for that matter) resolution through the terminal API. I agree. The mode setting should be done in one layer. Its a matter of doing the proper emulation of the fbdev layer. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Thu, Mar 11, 2010 at 02:22:14AM +, James Simmons wrote: There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. Yes the mapping issue were never address. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. Actually that is what I had in mind when I reworked the fbdev api. Plus with the linux console project I got multiple VTs working at the same time. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. Not true. You can map different displays to different vcs. Give con2fb a try some time :-) I know about it but only one VT can be active at any given time. Now there is the issue of more than one keyboard being mapped at a time. BTW I did getting multipe VT working at the same time working in the past. It requires some cleanup on the console layer. Well if you think that cleanup is possible and worth the effort then it might make sense. The crtc-output mapping is still unresolved though and it depends on hardware which combinations are supported. If for example the hardware can't drive multiple outputs with the same CRTC or if the outputs require totally different timings then you can't clone the same VT to multiple outputs. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 3 March 2010 06:02, Dave Airlie airl...@gmail.com wrote: On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek hramr...@centrum.cz wrote: On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. What about writing a drmfbset or something and have fbset call it when it detects a drm framebuffer and warn that it does not support drm framebuffers fully? That way people using fbset still get something and people who want exact control over the setup can use the new tool which uses whatever KMS interface is available already. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. What about writing a drmfbset or something and have fbset call it when it detects a drm framebuffer and warn that it does not support drm framebuffers fully? My main problem with calling the drm underneath the fbdev is it seems like a layering violation. Then again some of code in the kernel is also contributing to this violation. I'd really like to make fbdev more like an in-kernel version of what X driver have to do, and leave all the initial modepicking etc to the fbdev interface layer. If we take the layering as fbcon - fbdev - kms - hw I feel calling ioctls on the KMS layer from userspace to do stuff for fbcon or fbdev is wrong, and we should rather expose a more intelligent set of ioctls via the fbdev device node. This points at quite a bit of typing. So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev drivers do, and then a new fbset could tkae advantage of these. I'm not sure how much different to the current kms interface or how powerful we really need to make tihs interface though, and I feel kinda bad implementing it without some idea what users would want from it. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 3 March 2010 10:23, Dave Airlie airl...@gmail.com wrote: I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. What about writing a drmfbset or something and have fbset call it when it detects a drm framebuffer and warn that it does not support drm framebuffers fully? My main problem with calling the drm underneath the fbdev is it seems like a layering violation. Then again some of code in the kernel is also contributing to this violation. I'd really like to make fbdev more like an in-kernel version of what X driver have to do, and leave all the initial modepicking etc to the fbdev interface layer. If we take the layering as fbcon - fbdev - kms - hw I feel calling ioctls on the KMS layer from userspace to do stuff for fbcon or fbdev is wrong, and we should rather expose a more intelligent set of ioctls via the fbdev device node. This points at quite a bit of typing. I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. You set the proper options on the proper layer - fonts in fbcons, resolution in fbdev or the driver (which sucks but so far nobody came up with a modesetting solution universal enough to work with all drivers), and some hardware-specific options in the driver as well. Still if most framebuffer drivers are converted to KMS there would not be interface discrepancies. KMS would be used to set resolution and fbdev to draw on the screen. So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev drivers do, and then a new fbset could tkae advantage of these. I'm not sure how much different to the current kms interface or how powerful we really need to make tihs interface though, and I feel kinda bad implementing it without some idea what users would want from it. I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Designing an unified multihead fbdev extension interface would probably take quite a bit of typing and time. It would also help to have something working to compare to. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek hramr...@centrum.cz wrote: On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. Thanks Michal -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 11/20/2009 10:01 PM, James Simmons wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckaspaulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. IMHO this patch should end up in current (2.6.32) kernel and we should send it to stable ML. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 11/20/2009 09:05 PM, Andrew Morton wrote: On Fri, 20 Nov 2009 18:53:37 + (GMT) James Simmonsjsimm...@infradead.org wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckas paulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. While at this patch maybe you should fix that spelling issue as well. cheers, lkml resendbot. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html P.S. check CLCOK spelling :) This patch got lost during fb helper reorganization: http://git.kernel.org/linus/1bcbf3948876e31a8ece28597dec447611ad9c8b Regards, Clemens -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, 20 Nov 2009 18:53:37 + (GMT) James Simmons jsimm...@infradead.org wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlie airl...@linux.ie Dave Airlie airl...@redhat.com Jesse Barnes jbar...@virtuousgeek.org Mikael Pettersson mi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. cheers, lkml resendbot. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckas paulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, 20 Nov 2009, Paulius Zaleckas wrote: On 11/20/2009 10:01 PM, James Simmons wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckaspaulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. IMHO this patch should end up in current (2.6.32) kernel and we should send it to stable ML. Honestly I like to see it there as well. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Sat, Nov 21, 2009 at 6:48 AM, James Simmons jsimm...@infradead.org wrote: On Fri, 20 Nov 2009, Paulius Zaleckas wrote: On 11/20/2009 10:01 PM, James Simmons wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckaspaulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. IMHO this patch should end up in current (2.6.32) kernel and we should send it to stable ML. Honestly I like to see it there as well. I have them queued for drm-next already at least locally, I wasn't aware they were suitable for final, I didn't get a chance to really test them until last week and make sure they didn't hide any side effects. I can ask for them to go to stable when the merge window opens, I think its too late for final. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
paulius.zalec...@gmail.com wrote:
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
[...]
if (var-pixclock == -1 || !var-pixclock)
return -EINVAL;
[...]
int drm_fb_helper_set_par(struct fb_info *info)
{
[...]
if (var-pixclock != -1) {
DRM_ERROR(PIXEL CLCOK SET\n);
return -EINVAL;
}
[...]
One of these evaluations will fail regardless of pixclock value.
At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,
Now if a user runs fbset, I'm not sure what the right answer is,
a) pick a head in advance via sysfs maybe and set it on that.
b) try and set the mode on both heads cloned (what to do if
there is no common mode is another issue).
Dave.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
