From: Denis Oliver Kropp <hidden> Date: 2008-05-28 14:59:16
Hi,
after getting too depressed by the current state of the FBDev backend with the new
surface core I decided to drop FBDev support as it no longer fits into the architecture.
If you feel you like to fix the frame buffer device system module or better the frame
buffer device itself, you're welcome to help the FBDev backend to creep over the 1.2 hurdle...
One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
return the pitch of the variable mode settings in the fixed settings structure anyhow, but
if you like to start with the above mentioned mission, that's where it could begin.
And while you're at it, please also add an ioctl to just simply set the display offset without
a virtual resolution and x/y offset values within the whole frame buffer...
I have no idea why the FBDev backend uses the wrong pitch (4096) after switching to RGB16 which
should have a pitch of 2048. One out of ten tries did work though. I remember it has been
working once I added several workarounds and hacks to keep the FBDev backend alive, but somehow
the code or core have changed, I don't know and I'm not in the mood of spending time on cruft
like VTs, FBDev etc...
Volunteers are welcome, urgently, I'm going to make a first release candidate of 1.2 tomorrow,
most likely after removing the fbdev system module.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Hi Denis,
On Wed, 28 May 2008, Denis Oliver Kropp wrote:
One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
return the pitch of the variable mode settings in the fixed settings structure anyhow, but
if you like to start with the above mentioned mission, that's where it could begin.
Do you care to tell us why this is dumb?
The pitch depends on the video mode and the hardware requirements,
that's why it's in struct fb_fix_screeninfo.
And while you're at it, please also add an ioctl to just simply set the display offset without
a virtual resolution and x/y offset values within the whole frame buffer...
Why do you need this? What's different compared to setting a virtual
resolution and a y offset (I assume you're talking about y only, as an x
offset without a virtual resolution doesn't make much sense).
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
From: Denis Oliver Kropp <hidden> Date: 2008-05-28 17:20:39
Geert Uytterhoeven wrote:
Hi Denis,
On Wed, 28 May 2008, Denis Oliver Kropp wrote:
quoted
One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
return the pitch of the variable mode settings in the fixed settings structure anyhow, but
if you like to start with the above mentioned mission, that's where it could begin.
Do you care to tell us why this is dumb?
Ok, the fixed information should not contain information that changes over time,
otherwise it is not fixed, at least that's my understanding of "fixed".
The pitch depends on the video mode and the hardware requirements,
that's why it's in struct fb_fix_screeninfo.
It would suffice to encode the pitch requirements independent from the video mode,
i.e. just put the pixel or byte alignment into the fixed structure.
quoted
And while you're at it, please also add an ioctl to just simply set the display offset without
a virtual resolution and x/y offset values within the whole frame buffer...
Why do you need this? What's different compared to setting a virtual
resolution and a y offset (I assume you're talking about y only, as an x
offset without a virtual resolution doesn't make much sense).
If you see the frame buffer as a big pool of memory in which you can allocate chunks
for being displayed or otherwise used by the hardware, it is a handicap if you need to
specify the offset of these buffers in non-linear mode after putting some 2D coordinate
system onto the 1D memory area.
I'd propose to allow user space to choose any byte offset and pitch as part of the variable
information that is compatible with the hardware. To achieve this the constrains should be
put into the fixed information.
fb_var_screeninfo
- remove/disable x_offset/y_offset
+ add byte_offset/byte_pitch
fb_fix_screeninfo
- remove variable pitch info
+ add byte/pixel alignment constrains for offset and pitch
Furthermore, the pan_display functionality could be enhanced to allow a kernel side queue
for frame accurate display of several buffers, e.g. video playback with five or more buffers
pre-rendered. A frame/sync counter and some new flags would be enough to be added for this.
Ville Syrjala once did an extension like FBIO_FLIP or similar, maybe he can elaborate.
I'm also seeing the need to have one pool of memory used by different frame buffer devices
or some other way to support multiple layers without statically partitioning memory that could
be managed more intelligently.
And how about such capabilities like layer opacity, alpha ramps...?
I know all this was not required to run the kernel based terminal emulation that the frame
buffer device has been invented for :)
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
One major bug at the moment is mode switching and pitch values being
wrong. It's dumb to
return the pitch of the variable mode settings in the fixed settings
structure anyhow, but
if you like to start with the above mentioned mission, that's where it
could begin.
Do you care to tell us why this is dumb?
Ok, the fixed information should not contain information that changes over
time,
otherwise it is not fixed, at least that's my understanding of "fixed".
It's `fixed' not in the sense that it can never change, but that it
purely depends on the info in struct fb_var_screeninfo.
quoted
The pitch depends on the video mode and the hardware requirements,
that's why it's in struct fb_fix_screeninfo.
It would suffice to encode the pitch requirements independent from the video
mode,
i.e. just put the pixel or byte alignment into the fixed structure.
What if the pitch requirements depend on the video mode?
There exists graphics hardware where fb_fix_screeninfo.type depends on
the video mode.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
From: Denis Oliver Kropp <hidden> Date: 2008-05-28 18:35:01
Geert Uytterhoeven wrote:
On Wed, 28 May 2008, Denis Oliver Kropp wrote:
quoted
Geert Uytterhoeven wrote:
quoted
On Wed, 28 May 2008, Denis Oliver Kropp wrote:
quoted
One major bug at the moment is mode switching and pitch values being
wrong. It's dumb to
return the pitch of the variable mode settings in the fixed settings
structure anyhow, but
if you like to start with the above mentioned mission, that's where it
could begin.
Do you care to tell us why this is dumb?
Ok, the fixed information should not contain information that changes over
time,
otherwise it is not fixed, at least that's my understanding of "fixed".
It's `fixed' not in the sense that it can never change, but that it
purely depends on the info in struct fb_var_screeninfo.
I'd prefer an ioctl which has input and output fields in the accompanied struct,
so that the resulting pitch is returned to the user space with the same system call.
quoted
quoted
The pitch depends on the video mode and the hardware requirements,
that's why it's in struct fb_fix_screeninfo.
It would suffice to encode the pitch requirements independent from the video
mode,
i.e. just put the pixel or byte alignment into the fixed structure.
What if the pitch requirements depend on the video mode?
Haven't seen that, usually either pixels or bytes just needs to be a multiple
of something. In these cases you could simply forbid/fail to choose the pitch and
just return it in the variable structure.
There exists graphics hardware where fb_fix_screeninfo.type depends on
the video mode.
Sure, type depends on the pixelformat :)
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/