Uwe,
On Monday 08 October 2007 12:11, Uwe Hermann wrote:
you will need a special driver. You can find it in the BSP in the local_src/xf86-video-geode_gx1 directory.
Same here, will it be merged into xorg?
I'm not an Xorg expert. So this code is unfinished and more of type "works for me". But on the other hand same as with the kernel: Too specific for ways to old hardware...
This one is probably more likely to make it into mainline. I see no reason for the xorg developers to reject the driver. The hardware being a bit old is surely not a reason. This was a very popular chipset for set-top-boxes and thin clients and they're still readily available on ebay for almost no money...
I think no chance for mainline. The original driver relies on SMM, my Xorg driver relies on my console driver (for example to handle the scratch pad RAM, needed for hardware acceleration). How could one handle this?
In my daily work I must handle tons of patch stacks. So the patch stacks in my BSP are no problem (at least for me), I can life with it. And with my BSP I give everyone a chance to use them without the knowledge what's going on. IMHO someone who is able to configure LinuxBIOS and replace his flash content is also able to handle some patches for his kernel. =8-)
Gimmick only. This graphic file is autogenerated with a small program that converts xpm into C code.
Doesn't gimp have a similar option, too? If your code could handle the output of that gimp plugin (it's shipped per default, I think) that would be a great and easy way for users to create their own icons without requiring extra command line tools.
Sorry, I don't know Gimp and its many features. Can you generate such a Gimp output from a small picture and send it offline? I will create a patch to supports Gimp's output.
Here's an example.
$ wget http://linuxbios.org/images/d/d3/Chip_lb.png $ gimp Chip_lb.png -> Right-click into the image -> Save as -> C source file
Output:
/* GIMP RGBA C-Source image dump (Chip_lb.c) */
static const struct { unsigned int width; unsigned int height; unsigned int bytes_per_pixel; /* 3:RGB, 4:RGBA */ unsigned char pixel_data[65 * 75 * 4 + 1]; } gimp_image = { 65, 75, 4,
Uhhh, it uses RGB values for each pixel. We can use it, no problem, but every bitmap will be very large. Is there also an index based format supported? With a colour look up table (like my format)?
Juergen