Menu
▾
▴
linux-fbdev-devel
|
From: Michael K. <kau...@so...> - 2002-12-13 16:35:37
|
Hello, i would like to use a mono LCD with a framebuffer driver. I've modified existing drivers, and after a lot of work i now have a clea= r picture on my display. Unfortunately, the complete picture is mirrored. The Bootlogo is top/right instead of top/left and the ascii output starts= from=20 right to left.=20 Where is the right place to modify this behaviour?=20 I'm also looking for a possibility to rotate the picture. Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp. It would be very nice, if someone can guide me in the right direction. Thanks in advance! Michael=20 |
|
From: Antonino D. <ad...@po...> - 2002-12-14 21:35:21
|
On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote: > Hello, > > i would like to use a mono LCD with a framebuffer driver. > > I've modified existing drivers, and after a lot of work i now have a clear > picture on my display. Unfortunately, the complete picture is mirrored. > The Bootlogo is top/right instead of top/left and the ascii output starts from > right to left. > > Where is the right place to modify this behaviour? > I'm also looking for a possibility to rotate the picture. > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp. > > It would be very nice, if someone can guide me in the right direction. > Are you using fbcon-cfb4.c to draw the characters? Is the whole display mirrored, including individual characters? If you run an fb-based app (like fbtest for instance), is the display also mirrored? If it's the whole display, maybe your hardware supports mirroring (some hardware with video overlay need this to support YUV formats that are either vertically or horizontally mirrored). Maybe it has something like that. Otherwise, it will be difficult to correct this without rewriting practically everything. Tony |
|
From: Michael K. <kau...@so...> - 2002-12-15 15:05:29
Attachments:
FB_with_cfb4.png
|
On Saturday 14 December 2002 23:29, you wrote:
> On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote:
> > Hello,
> >
> > i would like to use a mono LCD with a framebuffer driver.
> >
> > I've modified existing drivers, and after a lot of work i now have a
> > clear picture on my display. Unfortunately, the complete picture is
> > mirrored. The Bootlogo is top/right instead of top/left and the ascii
> > output starts from right to left.
> >
> > Where is the right place to modify this behaviour?
> > I'm also looking for a possibility to rotate the picture.
> > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp=
=2E
> >
> > It would be very nice, if someone can guide me in the right direction=
=2E
>
> Are you using fbcon-cfb4.c to draw the characters? Is the whole displa=
y
> mirrored, including individual characters? If you run an fb-based app
> (like fbtest for instance), is the display also mirrored?
Yes, i'm using fbon-cfb4.c. The console is on my display, i see the boot=
logo=20
and the kernel messages in the display mirrored. I never used fbtest. By =
the=20
way, where can i find fbtest? But i already startet nanox/microwindows on=
top=20
of the fb, and the picture is also mirrored. =20
> If it's the whole display, maybe your hardware supports mirroring (some
> hardware with video overlay need this to support YUV formats that are
> either vertically or horizontally mirrored). Maybe it has something
> like that. Otherwise, it will be difficult to correct this without
> rewriting practically everything.
No, i don't think so. It is a simple video controller. Nevertheless, i ha=
ve=20
just looked in the datasheet, and do not found such a feature.=20
I don't think that this is a bug or something like this in the framebuffe=
r.=20
Because everthing works like i exect it, but i have to mirror the picture=
=2E
I have also measured with a scope all signals to the display, and the=20
generated output looks like i expect it. The datastream starts with the f=
irst=20
pixel (in the picture top/left) and continues with the second pixel (on t=
he=20
right of the first pixel) and so on.
But my display is mapping this datastream from the right to the left.
Please take a look on the attached picture, i think it explains the behav=
iour.
I can reproduce it without Linux with a simple monitor programm
At the moment i have two explanations:
1) I have a display witch must be accessed unusual, and the LINUX FB does=
n't
support this kind of access (not yet).
2) There is a hardware problem with the signals to the display (changed=20
signals like frame-pulse, and line-pulse, or something like this.
I don't think that it is a hardware problem, but i will check the connect=
ion=20
again. Is there really no way in the framebuffer to mirror and/or rotate =
the=20
picture data?
When i have to fix it in software, what kind of code do i have to rewrite=
?=20
And, thank's for your reply!
=20
Bye
Michael |
|
From: Antonino D. <ad...@po...> - 2002-12-15 18:03:39
|
On Sun, 2002-12-15 at 22:03, Michael Kaufmann wrote: > On Saturday 14 December 2002 23:29, you wrote: > > On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote: > > > Hello, > > > > > > i would like to use a mono LCD with a framebuffer driver. > > > > > > I've modified existing drivers, and after a lot of work i now have a > > > clear picture on my display. Unfortunately, the complete picture is > > > mirrored. The Bootlogo is top/right instead of top/left and the ascii > > > output starts from right to left. > > > > > > Where is the right place to modify this behaviour? > > > I'm also looking for a possibility to rotate the picture. > > > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp. > > > > > > It would be very nice, if someone can guide me in the right direction. > > > > Are you using fbcon-cfb4.c to draw the characters? Is the whole display > > mirrored, including individual characters? If you run an fb-based app > > (like fbtest for instance), is the display also mirrored? > > Yes, i'm using fbon-cfb4.c. The console is on my display, i see the boot logo > and the kernel messages in the display mirrored. I never used fbtest. By the > way, where can i find fbtest? But i already startet nanox/microwindows on top Check one of the links in www.linux-fbdev.org. > of the fb, and the picture is also mirrored. > Ouch, your user apps are also mirrored :-( > > If it's the whole display, maybe your hardware supports mirroring (some > > hardware with video overlay need this to support YUV formats that are > > either vertically or horizontally mirrored). Maybe it has something > > like that. Otherwise, it will be difficult to correct this without > > rewriting practically everything. > > No, i don't think so. It is a simple video controller. Nevertheless, i have > just looked in the datasheet, and do not found such a feature. > > I don't think that this is a bug or something like this in the framebuffer. > Because everthing works like i exect it, but i have to mirror the picture. No, I never said this was a bug. Mirroring is a hardware feature occasionally useful such as for mirrored mpegs. > I have also measured with a scope all signals to the display, and the > generated output looks like i expect it. The datastream starts with the first > pixel (in the picture top/left) and continues with the second pixel (on the > right of the first pixel) and so on. > But my display is mapping this datastream from the right to the left. This is the problem. You are writing each byte in the correct location in the framebuffer, but somehow it gets shown in the "mirrored" location of your display. > Please take a look on the attached picture, i think it explains the behaviour. > I can reproduce it without Linux with a simple monitor programm > > At the moment i have two explanations: > 1) I have a display witch must be accessed unusual, and the LINUX FB doesn't > support this kind of access (not yet). > 2) There is a hardware problem with the signals to the display (changed > signals like frame-pulse, and line-pulse, or something like this. > > I don't think that it is a hardware problem, but i will check the connection > again. Is there really no way in the framebuffer to mirror and/or rotate the > picture data? > When i have to fix it in software, what kind of code do i have to rewrite? Fixing the console is feasible enough though it entails a lot of work. You have to rewrite all the functions in fbcon-cfb4.c so you go "right->left" instead of "left->right". Do the same thing to fbcon_show_logo() in fbcon.c, and fb_read/fb_write in fbmem.c. Fixing user apps, that's the tough part. The framebuffer API is not something like XAA which has specific hooks for filling, copying, expanding, etc an area of pixels to the framebuffer. All the framebuffer API provides are two ways to access the graphics memory (similar to a watered-down version of X's DGA): 1. The standard file read/file write which will be intercepted by fb_read and fb_write; and 2. mmap Of the 2, mmap is usually chosen by user apps because it's simple and fast. The disadvantage is that your driver has no control on what will get displayed, and there is no feasible solution to this, except to disable mmap by setting fb_fix_screeninfo.smem_len to zero. Hopefully, if mmap is not possible, they will fall back to using file read and file write. User apps will always assume that the first pixel written to the framebuffer will appear as the first pixel of the first scanline of your display. Meaning, for apps that will always use mmap, you have to rewrite them so they raster "right->left" instead of "left->right". If you think about it, a hardware solution seems to be more feasible. Tony |
|
From: Michel <mi...@da...> - 2002-12-16 00:40:59
|
On Son, 2002-12-15 at 21:57, Antonino Daplas wrote: >=20 > User apps will always assume that the first pixel written to the > framebuffer will appear as the first pixel of the first scanline of your > display. Meaning, for apps that will always use mmap, you have to > rewrite them so they raster "right->left" instead of "left->right". >=20 > If you think about it, a hardware solution seems to be more feasible. This may be true in general, but at least for X it wouldn't be hard to add an option for mirroring via a shadow framebuffer. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: James S. <jsi...@in...> - 2002-12-20 19:53:25
|
> I've modified existing drivers, and after a lot of work i now have a clear > picture on my display. Unfortunately, the complete picture is mirrored. > The Bootlogo is top/right instead of top/left and the ascii output starts from > right to left. Some hardware supports mirroring. Sounds like you turned it on by mistake. > Where is the right place to modify this behaviour? > I'm also looking for a possibility to rotate the picture. > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp. The latest 2.5.X kernels have hardware hooks for rotation. I haven't added it yet to the software accel functions. I plan to a soon as I get time. Thank you. |
|
From: Michael K. <kau...@so...> - 2002-12-23 11:06:39
|
Dear James, thanks for your reply. On Friday 20 December 2002 18:49, you wrote: > > I've modified existing drivers, and after a lot of work i now have a > > clear picture on my display. Unfortunately, the complete picture is > > mirrored. The Bootlogo is top/right instead of top/left and the ascii > > output starts from right to left. > > Some hardware supports mirroring. Sounds like you turned it on by mista= ke. No, there is nothing i could turn on/off in my hardware.=20 I have checked the hardware and the datasheets again, and i'm now sure. T= he=20 display i'm using is a LCD monochrom display. And this type of display wr= ites=20 the picture date from right to left (mirrored). There is nothing i can do= =20 against it. My videocontroller has no feature to output every line mirror= ed. The videocontroller start sending the picture datastream to the display f= rom videobuffer address 0. The first pixel from the picture datastream will b= e=20 displayed on the right/top edge on my LCD and the second pixel left to th= e=20 first and so on.=20 First i thought that this behaviour of my display is extremly unusal. Aft= er=20 looking to other display datasheets i now know, that it is unusal but far= not=20 sooo unusual i thought the first time. =20 > > Where is the right place to modify this behaviour? > > I'm also looking for a possibility to rotate the picture. > > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp= =2E > > The latest 2.5.X kernels have hardware hooks for rotation. I haven't ad= ded > it yet to the software accel functions. I plan to a soon as I get time. > Thank you. Antonino has also answered to my question. And he said that there is noth= ing=20 i can do, because user apps will directly acces the framebuffer via read/= write=20 or nmap. I can only patch the console and the show _logo to write the dat= a=20 mirrored to the videobuffer (a lot of work). So my user apps (like nanoX or directfb/GTK+) must know about the mirrore= d=20 display and should write the picturedata mirrored in the framebuffer.=20 I'm know a litte bit amazed about a rotation feature in next versions. Do= es=20 this mean, that the buffer where user apps (or also the console) are writ= ing=20 there picture data is not directly the videobuffer anymore? Or how does t= his=20 rotation feature works? I think it would be a good feature to have 'something' between the frameb= uffer=20 and the physical videobuffer to be able to manipulate the picture data (l= ike=20 rotation, mirroring, etc.). But i don't know how this peace of software=20 should detect, changed data in the 'framebuffer' to e.g. mirror in the=20 videobuffer? Writing the whole buffers from time to time whould be a very bad solution (performance). At the moment i plan to do the manipulation in the directfb layer on top = of=20 the framebuffer device. I 'only' need to run some GTK+ applications. I ne= ed=20 to mirror the picture, and i also want to rotate the picture from landcap= e to=20 portrait. Bye Michael=20 |
|
From: Antonino D. <ad...@po...> - 2002-12-29 16:13:08
|
On Mon, 2002-12-23 at 21:04, Michael Kaufmann wrote: > Antonino has also answered to my question. And he said that there is nothing > i can do, because user apps will directly acces the framebuffer via read/write > or nmap. I can only patch the console and the show _logo to write the data > mirrored to the videobuffer (a lot of work). > So my user apps (like nanoX or directfb/GTK+) must know about the mirrored > display and should write the picturedata mirrored in the framebuffer. > > I'm know a litte bit amazed about a rotation feature in next versions. Does > this mean, that the buffer where user apps (or also the console) are writing > there picture data is not directly the videobuffer anymore? Or how does this > rotation feature works? I think the rotation hooks are console specific. > > I think it would be a good feature to have 'something' between the framebuffer > and the physical videobuffer to be able to manipulate the picture data (like That is the job of fb libraries. You can use X (which already has support for rotation, so mirroring should be easy to add), or modify DirectFB. > rotation, mirroring, etc.). But i don't know how this peace of software > should detect, changed data in the 'framebuffer' to e.g. mirror in the > videobuffer? Writing the whole buffers from time to time whould be a very > bad solution (performance). You can probably implement something similar to a shadow framebuffer. You expose this instead of the actual framebuffer (fix->smem_start, and info->screen_base), then just refresh the contents of the actual framebuffer, say during vsync. You will have to set up a vsync irq_handler or something similar. Tony |
|
From: James S. <jsi...@in...> - 2003-01-07 21:19:25
|
> > I'm know a litte bit amazed about a rotation feature in next versions. Does > > this mean, that the buffer where user apps (or also the console) are writing > > there picture data is not directly the videobuffer anymore? Or how does this > > rotation feature works? > I think the rotation hooks are console specific. Actually the low level drivers can use the hooks. |
Thanks for helping keep SourceForge clean.
X