> > > > 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.
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
>
> > 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 t
On Mon, 2010-03-15 at 18:38 +, James Simmons 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/msg
> > 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
> > 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_
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 A
>
> 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
> >> 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 b
>> >
>> >> >> 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 o
On Thu, 11 Mar 2010, Michal Suchanek wrote:
> On 11 March 2010 16:17, James Simmons 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
On 11 March 2010 16:17, James Simmons 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?
>> >
>> >
> >> 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
2010/3/11 Michel Dänzer :
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons
>> > wrote:
>> >>
>> >> See my other post about what fbdev really means in its historical
>> >> context.
2010/3/11 Michel Dänzer :
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons
>> > wrote:
>> >>
>> >> See my other post about what fbdev really means in its historical
>> >> context.
On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher wrote:
> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons
> > wrote:
> >>
> >> See my other post about what fbdev really means in its historical
> >> context. The struct fb_info really maps b
On 10 March 2010 19:47, James Simmons 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 frameb
On 10 March 2010 18:42, James Simmons 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 supp
On 10 March 2010 22:04, Ville Syrjälä 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 framebuffe
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
> > > specia
> > 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.
> > 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
> > > 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 d
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
On Wed, Mar 10, 2010 at 1:47 PM, James Simmons 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 t
> >> 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 framebuff
> 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 h
On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher wrote:
> On Wed, Mar 10, 2010 at 12:42 PM, James Simmons
> 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
On Wed, Mar 10, 2010 at 12:42 PM, James Simmons 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 fbs
> 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
> initi
> >> 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'v
> On 21 November 2009 05:27, Dave Airlie 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 t
On 3 March 2010 10:23, Dave Airlie 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 in
>>
>>
>> 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/d
On 3 March 2010 06:02, Dave Airlie wrote:
> On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek wrote:
>> On 21 November 2009 05:27, Dave Airlie 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
>>> co
On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek wrote:
> On 21 November 2009 05:27, Dave Airlie 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
On 21 November 2009 05:27, Dave Airlie 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 res
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@lis
On 11/20/2009 09:05 PM, Andrew Morton wrote:
> On Fri, 20 Nov 2009 18:53:37 + (GMT)
> 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: ...
>>>
>>> p
On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
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,
> struc
On Sat, Nov 21, 2009 at 6:48 AM, James Simmons 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, 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 ev
> > > > 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.
On Fri, 20 Nov 2009 18:53:37 + (GMT)
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
> 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
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 d
46 matches
Mail list logo
