All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: Antonino Daplas <adaplas@pol.net>
Cc: Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods
Date: Sat, 4 Jan 2003 21:41:31 +0100	[thread overview]
Message-ID: <20030104204131.GD1319@ppc.vc.cvut.cz> (raw)
In-Reply-To: <1041672313.958.17.camel@localhost.localdomain>

On Sat, Jan 04, 2003 at 05:25:14PM +0800, Antonino Daplas wrote:
> Attached is a patch against 2.5.54 in an attempt to add putcs() and
> setfont() methods for fbdev drivers that require them:

Looks good.
 
> ...
> struct fb_char {
> 	__u32 dx;               /* where to place chars, in pixels */
> 	__u32 dy;               /* where to place chars, in scanline */

These two are questionable. I do not know what DaveM will need, but
I'll be happier with character coordinates for text mode. So for me it is
just question whether I'll do divide by width/height stored from setfont
in text mode, or multiply when in graphics mode. So I must remember
character cell size in any case. But having multiply in matroxfb could 
save multiply here in generic code.

I have strong feeling that doing multiply in generic code, and then divide
in fbdev driver is waste of time, but if Dave is happier with pixel
coordinates, I can definitely live with it.

> 	__u32 len;              /* number of characters */
> 	__u32 fg_color;
> 	__u32 bg_color;        
> 	__u32 *data;            /* array of indices to fontdata */
> };
> 
> struct fb_fontdata {
> 	__u32 width;            /* font width */
> 	__u32 height;           /* font height */
> 	__u32 len;              /* number of characters */
> 	__u8  *data;            /* character map */
> };
> 
> ...
> 
>     /* upload character map */
>     int (*fb_setfont)(struct fb_info *info, const struct fb_fontdata
> *font);
>     /* write characters */
>     int (*fb_putcs)(struct fb_info *info, const struct fb_char *chars);
> 

It would be nice to have old accel_putcs() available for modules, so driver 
could decide on case-by-case basis whether it will use its own code or 
generic without touching pointer (without modifying potentially constant
fb_ops structure common to all fbdev instances).
						Thanks,
							Petr Vandrovec
							vandrove@vc.cvut.cz

  parent reply	other threads:[~2003-01-04 20:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-04  9:25 [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods Antonino Daplas
2003-01-04 14:00 ` Jurriaan
2003-01-04 21:08   ` James Simmons
2003-01-04 21:08     ` James Simmons
2003-01-04 20:41 ` Petr Vandrovec [this message]
2003-01-04 21:12   ` James Simmons
2003-01-04 21:12     ` James Simmons
2003-01-04 23:17     ` Petr Vandrovec
2003-01-04 23:17       ` Petr Vandrovec
2003-01-07 21:46       ` [Linux-fbdev-devel] " James Simmons
2003-01-04 21:07 ` James Simmons
2003-01-04 21:07   ` [Linux-fbdev-devel] " James Simmons
2003-01-04 22:06   ` Antonino Daplas
2003-01-07 21:43     ` James Simmons
2003-01-07 21:43       ` [Linux-fbdev-devel] " James Simmons
2003-01-04 23:30   ` Petr Vandrovec
2003-01-07 21:51     ` James Simmons
2003-01-08 10:47       ` Geert Uytterhoeven
2003-01-08 10:47         ` [Linux-fbdev-devel] " Geert Uytterhoeven
2003-01-08 18:19         ` Antonino Daplas
2003-01-08 18:19           ` [Linux-fbdev-devel] " Antonino Daplas
2003-01-09 18:09           ` James Simmons
2003-01-09 18:09             ` James Simmons
2003-01-09 20:54             ` Geert Uytterhoeven
2003-01-09 20:54               ` [Linux-fbdev-devel] " Geert Uytterhoeven
2003-01-09 21:25               ` James Simmons
2003-01-09 21:25                 ` James Simmons
2003-01-10 14:36             ` Antonino Daplas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030104204131.GD1319@ppc.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=adaplas@pol.net \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.