From: Moe W. <es...@an...> - 2003-04-11 22:30:01
|
Hello, does anyone know whether there are any plans to support the graphic mode of T6963c driven displays in lcd4linux? After some intensive googling it seems to me like there's no software/driver available to make use of the graphics mode with linux, yet. how good is the text-mode support in l4l anyways? thanks for any info! regards -- MW |
From: Michael R. <re...@eu...> - 2003-04-12 06:47:40
|
Hello, > does anyone know whether there are any plans to support the graphic mode of > T6963c driven displays in lcd4linux? After some intensive googling it seems > to me like there's no software/driver available to make use of the graphics > mode with linux, yet. Well, the T6963-driver supports graphic mode _only_ :-) The display is used as a raster device, all the font rendering, bar rendering and so on is done in lcd4linux. This way, you get "perfect" bars, because there's no limitation of user-defined characters as in other displays. > how good is the text-mode support in l4l anyways? non-existant :-) bye, Michael -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
From: Moe W. <es...@an...> - 2003-04-12 12:11:49
|
On Sat, Apr 12, 2003 at 08:47:22AM +0200, Michael Reinelt wrote: > Hello, > > >does anyone know whether there are any plans to support the graphic mode of > >T6963c driven displays in lcd4linux? After some intensive googling it > >seems > >to me like there's no software/driver available to make use of the graphics > >mode with linux, yet. > > Well, the T6963-driver supports graphic mode _only_ :-) Oh okay, now that does sound good! :) > The display is used as a raster device, all the font rendering, bar > rendering and so on is done in lcd4linux. This way, you get "perfect" > bars, because there's no limitation of user-defined characters as in > other displays. Got any screenshots of these? (just curious) > >how good is the text-mode support in l4l anyways? > > non-existant :-) Okay, I'll rephrase my question: How good is the graphics-mode support in l4l? ;) I mean; will I be limited to the chars and symbols offered by l4l, or can I actually dump small bitmaps to the display and/or control it pixelwise? If that's not possible yet, it will definately be the first thing I'll try to hack up once I got my display. I took a quick glance at the code and all the scary parallel-port stuff seems to be nicely wrapped, so I might actually be able to do it even tho my C is, *ahem*, rusty. ;) > bye, Michael Thanks for updating me! best regards -- MW |
From: Michael R. <re...@eu...> - 2003-04-12 13:27:33
|
Hi Moe, >>The display is used as a raster device, all the font rendering, bar >>rendering and so on is done in lcd4linux. This way, you get "perfect" >>bars, because there's no limitation of user-defined characters as in >>other displays. > > Got any screenshots of these? (just curious) Look at the web page (http://lcd4linux.sourceforge.net). The pixmap device is a Meta-Driver, The Output is the same as e.g. the X11-Driver (both are pixmap-devices) >>>how good is the text-mode support in l4l anyways? >> >>non-existant :-) > > > Okay, I'll rephrase my question: > How good is the graphics-mode support in l4l? ;) again: non-existant :-) Well, not really. The only widget which uses the graphic capabilities is the bar. I had some thoughts in mind about "plots" ore something, but never implemented them. > I mean; will I be limited to the chars and symbols offered by l4l, or can I > actually dump small bitmaps to the display and/or control it pixelwise? No, not at the moment. l4l does not support this, but the T6963-driver would. T6963.c uses pixmap.c, which provides sort of a "graphic framebuffer", where Textx and bars are rendered into. The flush() function within T6963.c sends this framebuffer to the display (using double-buffering to save bandwith). > If that's not possible yet, it will definately be > the first thing I'll try to hack up once I got my display. You are very welcome to do so! BUT! Do it within the pixmap device, so every other graphic display would have these features, too (without any changes to the driver!). At the moment, all the pixmap-drivers (X11, PNM, PNG) would have icons! > I took a quick glance at the code and all the scary parallel-port stuff seems > to be nicely wrapped, so I might actually be able to do it even tho my C is, > *ahem*, rusty. ;) If you plan to change something, _PLEASE_ use the CVS code! (I recently implemented a new "parallel port abstraction layer", so the parport stuff looks even cleaner now. Another thing: You don't have to wait for your display, use the X11 driver for development and testing. Believe me, as soon as you get your display, it will work. (And I sooner get your code :-) If you have any questions about the internal structure, feel free to ask me! I think you'd best start with pixmap.c, implementing some new functions which draw things into the framebuffer. Have fun! -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |