From: Otto Wyss <hidden> Date: 2002-09-10 20:44:38
I guess the framebuffer drivers so far don't support turning the display 90° as
the Pivot software does for Windows/MacOS. Since I'm considering buying a
turnable display I rather see this feature implemented. I even may help but can
spend much time. How difficult would it be?
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/")
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
I guess the framebuffer drivers so far don't support turning the display 90° as
the Pivot software does for Windows/MacOS. Since I'm considering buying a
I posted a patch under the thread titled "Console Rotation" 2 days ago.
It should support rotation in 3 additional directions (90, 180 and 270
degrees). As far as fb-based apps, they have to do the rotation on
their own. XFbdev in 4.2.0 already does that.
turnable display I rather see this feature implemented. I even may help but can
spend much time. How difficult would it be?
It should not be too difficult to add per-driver support once the
rotation wrappers are implemented. The main requirement is that the
driver must support the drawing primitives (xxxfillrect, xxxcopyarea,
xxximageblit -- main reason I like the primitives is because you can do
a lot of fancy things with minimal code change). I already did this
with VESA fb, and it required less than 100 lines of code.
Doing this in 2.4 will be trickier because of absence of support for
drawing primitives. (The i810fb driver had console rotation for half a
year now, though)
If you are interested, try the patches (apply them in the order I
mentioned). http://i810fb.sourceforge.net/fb_rotate.tar.gz
Tony
-------------------------------------------------------
In remembrance
www.osdn.com/911/
I guess the framebuffer drivers so far don't support turning the display 90° as
the Pivot software does for Windows/MacOS. Since I'm considering buying a
I posted a patch under the thread titled "Console Rotation" 2 days ago.
It should support rotation in 3 additional directions (90, 180 and 270
degrees). As far as fb-based apps, they have to do the rotation on
their own. XFbdev in 4.2.0 already does that.
quoted
turnable display I rather see this feature implemented. I even may help but can
spend much time. How difficult would it be?
It should not be too difficult to add per-driver support once the
Can't this be moved up to generic code, so we don't have to modify all drivers?
rotation wrappers are implemented. The main requirement is that the
driver must support the drawing primitives (xxxfillrect, xxxcopyarea,
xxximageblit -- main reason I like the primitives is because you can do
a lot of fancy things with minimal code change). I already did this
with VESA fb, and it required less than 100 lines of code.
Since in the end all drivers will, this is not a real issue.
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
-------------------------------------------------------
In remembrance
www.osdn.com/911/
On Wed, 2002-09-11 at 14:38, Geert Uytterhoeven wrote:
quoted
quoted
turnable display I rather see this feature implemented. I even may help but can
spend much time. How difficult would it be?
It should not be too difficult to add per-driver support once the
Can't this be moved up to generic code, so we don't have to modify all drivers?
I have thought about that, but since the patch was preliminary, I chose
not to disrupt the framework yet. The tricky part in making the support
generic is display panning.
Here is my train of thought. Moving support into fbgen might involve a
few assumptions. Firstly, info->var is assumed to be device specific
(ie, it does not care about the orientation). Secondly, the display->var
as well as those received from other sources (such as in an ioctl call)
are partly device independent. When a structure var is passed to the
driver, it will undergo conversion so the structure is sane from the
driver's perspective. The same is done vice-versa. I've introduced two
(exportable) functions, convert_var_to_physical(), and
convert_var_to_logical() that should do that.
All fbops functions should be passed with device-specific var except for
fb_set_var since I'm not too sure where to look for specific entry
points for fb_set_var. I guess fb_check_var and fb_pan_display are the
most critical ones, since the other fbops functions do not look at the
framelengths, nor the offsets.
With the changes, drivers that support fbcon_accel and gen_* functions
should have support for console rotation automatically.
For those that support fbcon_accel, but not gen_* functions, the driver
should not look at display->var anymore, but look instead into
info->var. If possible, use the convert_to_var functions when
passing/getting information to/from structure display.
For those, that don't support fbcon_accel, behaviour should remain as
usual.
I'm not too sure if this is the correct way of doing this, but it's the
best I can think of at the moment without causing very intrusive
changes.
Attached is a patch (fb_rotate2.diff). Please apply the patches I have
sent previously before applying this patch.
Tony
From: Otto Wyss <hidden> Date: 2002-09-11 20:18:40
I posted a patch under the thread titled "Console Rotation" 2 days ago.
It should support rotation in 3 additional directions (90, 180 and 270
degrees). As far as fb-based apps, they have to do the rotation on
I should have looked more closely at the messages, "Console ..." misguided me.
their own. XFbdev in 4.2.0 already does that.
When the fb drivers support rotation, XFbdev doesn't need rotation anymore.
Doing this in 2.4 will be trickier because of absence of support for
drawing primitives. (The i810fb driver had console rotation for half a
year now, though)
I'm currently using "aty128fb" but may be able to switch to "matroxfb". I'm also
considering buying card with an DVI plug (hopefully without fan :-( )
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/")
-------------------------------------------------------
In remembrance
www.osdn.com/911/
I posted a patch under the thread titled "Console Rotation" 2 days ago.
It should support rotation in 3 additional directions (90, 180 and 270
degrees). As far as fb-based apps, they have to do the rotation on
I should have looked more closely at the messages, "Console ..." misguided me.
quoted
their own. XFbdev in 4.2.0 already does that.
When the fb drivers support rotation, XFbdev doesn't need rotation anymore.
It really is just console rotation, all other fb-based apps would still
display in the standard "upright" position unless specifically written
for display rotation, such as Xfbdev.
quoted
Doing this in 2.4 will be trickier because of absence of support for
drawing primitives. (The i810fb driver had console rotation for half a
year now, though)
Does this mean I have to use 2.5 to get rotation?
I'm not sure if the patch I submitted will even be accepted. My point
is that it's easier to do this in the 2.5 fb framework than in 2.2-2.4.
But you can already use Xfbdev in 2.4 to rotate the display.
I'm currently using "aty128fb" but may be able to switch to "matroxfb". I'm also
considering buying card with an DVI plug (hopefully without fan :-( )
It depends if the driver maintainers will support the drawing
primitives. Some may refuse not to, and that is understandable.
Tony
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf