lkml.org 
[lkml]   [2004]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux-fbdev-devel] fbdv/fbcon pending problems

> Sure, hopefully fbdev drivers became more 'intelligent', with just a
>
> echo "1024x768x16-75" > /sys/class/fbdev/0/geometry
>
> they will compute internally the timings or get it from EDID and
> glad the user with something correct for the hardware.
>
> cat /sys/class/fbdev/0/modes
>
> will give you the modes supported by the card.

Yes.

> On the other side i see a lot of effort in the fbdev acceleration,
> it is nice but that effort should be better spent on fixing the layer,
> imo, the only user for acceleration is fbcon, any userland app that
> use fbdev disables that acceleration so it can map the vmem and ioregs,
> and do it's own voodoo if it wants acceleration. That acceleration
> is not "exported" to user space. I am working in a open source project
> that uses mesa-solo with fbdev and many limitations from the layer
> itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be
used for read and writes on /dev/fbX. Also it is used for software
cursors.

> By 'fixing the layer' i mean some simple things that could make fbdev
> a real graphics solution for linux in the long term:
>
> - fbdev_core (will handle the fbdev/sysfs registration, shared by all
> drivers, most important is the modes handling interface).

Pretty much done.

> - fbdev_xxx (driver for specific hw, it will only export the interesting
> bits like vmem, ioregs, will handle mmap stuff and ioctl's,
> video modes, no accel of any kind).

Have it.

> - fbdev_xxx_accel (acceleration hooks if any for xxx driver, optional module)

We need it for the above reasons.

> - fbdev_con (handle console -- already modular in 2.6, will use accel hooks
> if not NULL, optional).

We always need the accel hooks. Some how we have to draw the fonts.

> - fbdev_xxx_drm (will handle the DRM for xxx using hooks from fbdev, so we
> could have just a single entity inside the kernel handling a
> specific device, and not the current mess within fbdev and
> drm, optional).

That will be the future.

> We have now with 2.6 a good input and sound layers. Just by fixing
> the graphics layer many interesting userland projects could be born.

I agree. The graphics layer is the last frontier.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.083 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site