The code used in microwindows is almost the same as in fbdev.c
I've modified fbdevPutColors, so as to have a palette with "all green", and
it didn't worked, ie, colors didn't changed....
Today, I did the same change in microwindows code, but "all red", and it
works..... I've a nice but useless red screen, red cursor, red drawings :-)
This is(part of) the microwindows code:
.....................
void
ioctl_setpalette(int start, int len, short *red, short *green, short *blue)
{
struct fb_cmap cmap;
short c_r[256]; /* my code */
short c_g[256]; /* my code */
short c_b[256]; /* my code */
int i; /* my code */
for(i=0; i<256; i++) c_r[i]=0xff00; /* my code */
for(i=0; i<256; i++) c_g[i]=c_b[i]=0; /* my code */
cmap.start = start;
cmap.len = len;
cmap.red = c_r; /* my code */
cmap.green = c_g; /* my code */
cmap.blue = c_b; /* my code */
/*
cmap.red = red;
cmap.green = green;
cmap.blue = blue;
*/
cmap.transp = NULL;
ioctl(fb, FBIOPUTCMAP, &cmap);
}
....................................
Both codes are using ioct to access the color palette, and both codes uses
almost the same initialization for the framebuffer, except (or I'm not sure
about): microwindows is opening /dev/tty0 and ioctl's it to be in graphics
mode, ie: ioctl (tty, KDSETMODE, KD_GRAPHICS).
*) Microwindows runs in the same console from where it is opened. I only
have one console (I'm using busybox, and my init only has
::askfirst:/bin/ash), so microwindows runs in tty0.
*) kdrive runs in another console.... what I'm thinking is that kdrive is
changing another color palette, because I forced it to be "all green" and
nothing happends. Also, Matthew Allum said:
>Try launching tinyX not from a console ( ie in rc scripts ) or
>launching on another tty other than the current one.
>
>Make sense ?
>
>For some reason if you launch tinyX from a console, it gets the
>colormap all wrong.
So....if kdrive is really changing another color palette, or getting the
wrong colormap.... how can I fix it???
Meanwhile, I'll hardcode the color palette. As Christian says, it *must*
work, but, you know.... I'd rather prefer to use the kernel, and not bypass
it.... I'm having the same trouble with my ARM hardware and my x86 hardware
(Athlon).... and I would like to code to be portable...
Txs guys.
>From: Christian Berger <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [Xpert]kdrive
>Date: Fri, 2 Aug 2002 09:04:10 +0200
>
>Am Donnerstag, 1. August 2002 23:58 schrieben Sie:
> > >I don't think it's a problem with starting Xfbdev, it's a problem with
> > > the kernel. Just try to hardcode the "PutColours" function to directly
> > > access your Hardware and it might work.
> >
> > If it were the kernel.... why does microwindows framebuffer works ok?
> > The only thing that it is different (between microwindows and Xfbdev) is
> > that X runs in another console, microwindows runs in the same console
> > from where it is started...... maybe what I'm saying is totally stupid,
> > but...... but.....
>
>I don't, know could you look ate the put colours function of microwindows?
>II mean you already tried. The ioctl didn't work, did it?
>
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
