Menu
▾
▴
linux-fbdev-devel
|
From: Otto W. <ott...@bl...> - 2002-09-10 20:44:39
|
I guess the framebuffer drivers so far don't support turning the display =
90=B0 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 b=
ut can
spend much time. How difficult would it be?
O. Wyss
--=20
Author of "Debian partial mirror synch script"
=7F=7F=7F("http://dpartialmirror.sourceforge.net/")
|
|
From: Antonino D. <ad...@po...> - 2002-09-10 22:22:11
|
On Wed, 2002-09-11 at 04:44, Otto Wyss wrote: > I guess the framebuffer drivers so far don't support turning the display = 90=B0 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.=20 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 b= ut can > spend much time. How difficult would it be? >=20 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 |
|
From: Geert U. <ge...@li...> - 2002-09-11 06:38:24
|
On 11 Sep 2002, Antonino Daplas wrote:
> On Wed, 2002-09-11 at 04:44, Otto Wyss wrote:
> > I guess the framebuffer drivers so far don't support turning the disp=
lay 90=B0 as
> > the Pivot software does for Windows/MacOS. Since I'm considering buyi=
ng a
> I posted a patch under the thread titled "Console Rotation" 2 days ago.=
=20
> 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.
>=20
> > turnable display I rather see this feature implemented. I even may he=
lp but can
> > spend much time. How difficult would it be?
> >=20
> 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 dr=
ivers?
> 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-m6=
8k.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
|
|
From: Antonino D. <ad...@po...> - 2002-09-11 19:49:13
Attachments:
fb_rotate2.diff
|
On Wed, 2002-09-11 at 14:38, Geert Uytterhoeven wrote: > > > 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 W. <ott...@bl...> - 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) > Does this mean I have to use 2.5 to get rotation? > If you are interested, try the patches (apply them in the order I > mentioned). http://i810fb.sourceforge.net/fb_rotate.tar.gz > 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/") |
|
From: Antonino D. <ad...@po...> - 2002-09-12 18:37:57
|
On Thu, 2002-09-12 at 04:18, Otto Wyss wrote: > > 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. 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. > > > 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. > > > If you are interested, try the patches (apply them in the order I > > mentioned). http://i810fb.sourceforge.net/fb_rotate.tar.gz > > > 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 |
|
From: Antonino D. <ad...@po...> - 2002-09-16 03:08:35
|
On Mon, 2002-09-16 at 02:24, Otto Wyss wrote: > Sorry if I'm looking "heavy of understandig" (translated from German) but does > this mean that some parts are written with and some without rotation? Or does it > mean in console mode everything is rotated if the used driver supports it? Vise > versa X? > Diagramatically, the fb-based console looks something like this: Console -> fbcon -> fbdev -> graphics-capable hardware Rotation is done at the fbcon layer. fbdev on the other hand is just an abstraction of the underlying graphics hardware. It is fbdev that is actually used by fb-based applications, such as Xfree86. fbdev does not know about display orientation, but Xfbdev does, and so can fbcon. > What does a rotation unter X bring as long as the console doesn't? Okay for This is actually what triggered me to submit the patches, it is quite disconcerting to switch from a rotated Xfree86 display to an upright console. > anyone only using X the Xfbdev solution might be okay, but when the fb-diver > supports rotation Xfbdev should use this. See above. fbdev does not know about rotation, nor does it need to. Tony |
|
From: Otto W. <ott...@bl...> - 2002-09-17 17:50:27
|
> Diagramatically, the fb-based console looks something like this:
>
> Console -> fbcon -> fbdev -> graphics-capable hardware
>
> Rotation is done at the fbcon layer. fbdev on the other hand is just an
> abstraction of the underlying graphics hardware. It is fbdev that is
> actually used by fb-based applications, such as Xfree86. fbdev does not
> know about display orientation, but Xfbdev does, and so can fbcon.
>
What about applications compiled with GTK+ target linux-fb or similar toolsets?
If I understand it right only the fbcon layer should be used (if possible) to be
on the save side.
> > What does a rotation unter X bring as long as the console doesn't? Okay for
> This is actually what triggered me to submit the patches, it is quite
> disconcerting to switch from a rotated Xfree86 display to an upright
> console.
>
Okay I'm not so much interested in Xfbdev than in fbcon. Can you transferred
your code to the generic part as Geert Uytterhoeven already asked. I could help
test patches against kernel 2.4.19. And what about kernel 2.5, I've read of a
feature freeze soon?
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/")
|
|
From: Antonino D. <ad...@po...> - 2002-09-17 20:14:15
|
On Wed, 2002-09-18 at 01:50, Otto Wyss wrote: > > Diagramatically, the fb-based console looks something like this: > > > > Console -> fbcon -> fbdev -> graphics-capable hardware > > > > Rotation is done at the fbcon layer. fbdev on the other hand is just an > > abstraction of the underlying graphics hardware. It is fbdev that is > > actually used by fb-based applications, such as Xfree86. fbdev does not > > know about display orientation, but Xfbdev does, and so can fbcon. > > > What about applications compiled with GTK+ target linux-fb or similar toolsets? > If I understand it right only the fbcon layer should be used (if possible) to be > on the save side. > fbcon is text-based, so it's the same for all of them. If rotation is needed, it has to be added at the user level. I guess DirectFB is the best choice at the moment. Maybe you can ask the developers there for the possibility -- dir...@di.... > > > What does a rotation unter X bring as long as the console doesn't? Okay for > > This is actually what triggered me to submit the patches, it is quite > > disconcerting to switch from a rotated Xfree86 display to an upright > > console. > > > Okay I'm not so much interested in Xfbdev than in fbcon. Can you transferred > your code to the generic part as Geert Uytterhoeven already asked. I could help I already did, but it's against 2.5.33. See my response to Geert. It will only work if the driver itself uses the generic functions and has drawing primitives. It's very preliminary since James is still rewriting the FB framework. > test patches against kernel 2.4.19. And what about kernel 2.5, I've read of a > feature freeze soon? > In November, I think. Tony |
Thanks for helping keep SourceForge clean.
X