RE: [AD] fbcon directcolor modes patch, and possible other patches

["Vincent Penecherc'h" <Vincent.Penecherch@xxxxxxxxxx>]

[FB mode switch trouble snip]
> Can you describe this a bit more?

Setting a mode which has a different resolution that the
existing one (between 640x480 and 1024x768) changes to the
correct resolution, but the screen appears messed up. At a
first approximation, I'd say that the pitch is incorrect,
and possibly also the layout of the pixel format.
I am using radeonfb (new).
fbset works fine.

Following this, I had a go at checking if I could get away
with not changing the video mode if it was already the
correct one. I've made a new FB driver that "attaches" to
the current screen mode. It's quite nifty, you can map the
FB by calling "set_gfx_mode(GFX_AUTODETECT_ATTACH,0,0,0,0),
and modify the screen. I've even made an example program
that forks away and updates a clock on the screen corner.

Would that be interesting ? I can envision Allegro programs
writing over the framebuffer as a post process thing...

Would you be interested in this ?

> > - adding a lines array to RLE sprites (speeds up clipping)
> 
> *Probably* not interested.

IIRC, it is you who described the current clipping method as
almost criminal when you had a look :)

> > - 2 patches to check /dev/input/mice by default is the user
> >   supplied device doesn't work (in addition to /dev/mouse)
> 
> Sounds good.  That reminds me: we should make the evdev driver the
> default, though it had some cursor speed issues the last time 
> I checked.

OK, though I was wondering if the canonical way wasn't to
ln -s /dev/input/mice /dev/mouse for these cases. I guess
it makes sense to ln -s /dev/psaux /dev/mouse and still
have /dev/input/mice as a hub.

About EV speed, I don't know anything about that. Can you
give more info on that, bearing in mind that I've been out
of the list for ages ? I'll ask Annie if she knows about it,
she might already since she's written the driver.

> > - s/export/exporter/ in datedit.h (so it compiles when used
> >   by a C++ program, but breaks the datedit API)
> 
> We could do #ifdef __cplusplus so that C++ programs use 
> `exporter' but C
> programs use `export'.  But it's a field name and mostly people don't
> need to use the name directly so it should be fine just to change it.

OK. Though just including the header breaks C++ programs,
since it's a syntax error (keyword in a place that the parser
doesn't like).




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________