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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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?
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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: ...
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
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
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:
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
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: ...
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
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,
45 matches
Mail list logo
