linux-fbdev-users — Generic mailing list for users of frame buffers

[Linux-fbdev-users] Where to put fbset command during system boot up

[Kushal K. <kus...@ho...>]

Hi,

I am using Debian Etch with kernel 2.6.17 and I am using the framebuffer 
driver for my Graphic Card(AMD GX processor). Now the problem is, when my 
system boots on the framebuffer console, the resolution is "640x480" which I 
later found out once my system booted into fluxbox and I ran the fbset -v 
command to see the resolution of the framebuffer debvice. Now I know that my 
framebuffer driver supports "1024x768" resolution. I checked this my hitting 
Alt-Ctrl-F1 to switch from the fluxbox to the virtual console and then I 
gave the command fbset -v "1024x768-60" and the resolution got changed and I 
was getting a much bigger display now.

So my problem is how can I get that resolution during the system boot also. 
I tried putting a script called setconsole (which has a single line fbset -v 
"1024x768-60") in /etc/init.d directory and made it executable and linked it 
with the rc.N directories by giving the following command:

update-rc.d setconsole defaults 10

but it did not help.

How can get the particular resolution on my framebuffer console during the 
system boot? Do I need to place the script somewhere else?

THanks in advance.

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[James L. <ja...@ak...>]

I have a bit more work to do. I found that getting the color map right for
packed pixel mode, 565, was kind of tricky; as you had indicated. I also
realized that my code sort of relies on the fact that the color map is NOT
in use when the card is in bpp higher than 8. I use the color map to hold
shifted values from a palette bitmap file to get the colors onto the screen.
So I will have to rewrite that stuff; because with a direct color card, the
color map is always in use. I would love to send you a snapshot of my code.
It comes with a demo program that runs the video card through all sorts of
tests in every possible bpp.

James.   :o)


----- Original Message ----- 
From: "Antonino A. Daplas" <ad...@gm...>
To: <lin...@li...>; "James Lehman"
<ja...@ak...>
Sent: Sunday, August 06, 2006 7:42 PM
Subject: Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR
vs.FB_VISUAL_DIRECTCOLOR


> James Lehman wrote:
> > I'm not so sure there is a bug in the kernel or the drivers, but I can
say
> > for sure that this code gets called.
>
> Then it's a bug.
>
> Can you try removing fb_set_cmap() in driver/video/fbmem.c:fb_set_var()?
> If that still does not work, can you point me to a test app?
>
> Just to clarify, is this the sequence, or something near this?
>
> ...
> ioctl(KD_GRAPHICS);
> ...
> ioctl(FBIOPUT_VSCREENINFO);
>
> ioctl(FBIOPUTCMAP);
> ...
> ioctl(KD_TEXT);
> ...
>
> Tony
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Linux-fbdev-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users
>

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[Antonino A. D. <ad...@gm...>]

James Lehman wrote:
> I'm not so sure there is a bug in the kernel or the drivers, but I can say
> for sure that this code gets called.

Then it's a bug.

Can you try removing fb_set_cmap() in driver/video/fbmem.c:fb_set_var()?
If that still does not work, can you point me to a test app?

Just to clarify, is this the sequence, or something near this?

...
ioctl(KD_GRAPHICS);
...
ioctl(FBIOPUT_VSCREENINFO);

ioctl(FBIOPUTCMAP);
...
ioctl(KD_TEXT);
...

Tony

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[Antonino A. D. <ad...@gm...>]

Sean D'Epagnier wrote:
> On Sun, Aug 06, 2006 at 11:27:49AM +0800, Antonino A. Daplas wrote:
>> James Lehman wrote:
>>> But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32,
>>> it looks like the first 16 console colors have been written into the color
>>> map.
>>>
>> Try switching the VC to KD_GRAPHICS mode before you run your app. Then
>> switch it back to KD_TEXT on exit, ie:
>>
>> fd = open("/dev/tty0", FLAG);
>> ioctl(fd, KDSETMODE, KD_GRAPHICS);
>>
>> Let me know if doing the above still writes the console palette to the
>> cmap. That will be a bug.
>>
>> Tony
> 
> I have tried this, and no, KD_GRAPHICS does not seem to work, I think if you do not set to graphics mode while running, then you can restore the cmap by switching to graphics then text on exit.
> 
> I have found also that matroxfb does not need to set the cmap but nvidiafb does.
> 
> Does anyone know a use for directcolor other than gamma correction?

That's it. DirectFB also uses it to adjust saturation, brightness, etc
in admininistrative mode.

Tony

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[Sean D'E. <se...@de...>]

On Sun, Aug 06, 2006 at 11:27:49AM +0800, Antonino A. Daplas wrote:
> James Lehman wrote:
> > But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32,
> > it looks like the first 16 console colors have been written into the color
> > map.
> > 
> 
> Try switching the VC to KD_GRAPHICS mode before you run your app. Then
> switch it back to KD_TEXT on exit, ie:
> 
> fd = open("/dev/tty0", FLAG);
> ioctl(fd, KDSETMODE, KD_GRAPHICS);
> 
> Let me know if doing the above still writes the console palette to the
> cmap. That will be a bug.
> 
> Tony

I have tried this, and no, KD_GRAPHICS does not seem to work, I think if you do not set to graphics mode while running, then you can restore the cmap by switching to graphics then text on exit.

I have found also that matroxfb does not need to set the cmap but nvidiafb does.

Does anyone know a use for directcolor other than gamma correction?

thanks.

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[James L. <ja...@ak...>]

I'm not so sure there is a bug in the kernel or the drivers, but I can say
for sure that this code gets called.

I like to run frame buffer stuff like a high-res display server. I shell
into the box from another computer and have both a regular shell console and
the display that is native to the Linux box. If I shell in with another
console session and do anything that would open and init the frame buffer,
the problem disappears. I though I could get a screen shot of the problem,
but doing that makes it go away!

James.   :o)


//##########################################################################
##
int ezfb_tty_graphics()
{
    int ret = 1;
    if(0 > (tty = open(EZFB_TTY_DEVICE, O_RDWR)))
    {
        perror("\nezfb ERROR: " EZFB_TTY_DEVICE " open failed");
        ret = 0;
    }
    else if(0 > ioctl(tty, KDGETMODE, &tty_mode_was))
    {
        perror("\nezfb ERROR: " EZFB_TTY_DEVICE " get mode failed");
        ret = 0;
    }
    else if(    (KD_GRAPHICS != tty_mode_was)
             && (0 > ioctl(tty, KDSETMODE, KD_GRAPHICS)))
    {
        perror("\nezfb ERROR: " EZFB_TTY_DEVICE " set graphics failed");
        close(tty);
        ret = 0;
    }
    else
    {
        printf("tty mode was ");
        switch(tty_mode_was)
        {
            case KD_TEXT     :  printf("KD_TEXT"     ); break;
            case KD_GRAPHICS :  printf("KD_GRAPHICS" ); break;
            default          :  printf("IMPOSSIBLE!" ); break;
        }
        printf("\n");
        printf("tty mode set to KD_GRAPHICS\n");
        fflush(stdout);
        close(tty);
    }
    return ret;
}

//##########################################################################
##
int ezfb_tty_text()
{
    int ret = 1;
    if(0 > (tty = open(EZFB_TTY_DEVICE, O_RDWR)))
    {
        perror("\nezfb ERROR: " EZFB_TTY_DEVICE " open failed");
        ret = 0;
    }
    else if(0 > ioctl(tty, KDSETMODE, tty_mode_was))
    {
        perror("\nezfb ERROR: " EZFB_TTY_DEVICE " reset mode failed");
        close(tty);
        ret = 0;
    }
    else
    {
        printf("tty mode set to ");
        switch(tty_mode_was)
        {
            case KD_TEXT     :  printf("KD_TEXT"     ); break;
            case KD_GRAPHICS :  printf("KD_GRAPHICS" ); break;
            default          :  printf("IMPOSSIBLE!" ); break;
        }
        printf("\n");
        fflush(stdout);
        close(tty);
    }
    return ret;
}

//##########################################################################
##

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[Antonino A. D. <ad...@gm...>]

James Lehman wrote:
> But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32,
> it looks like the first 16 console colors have been written into the color
> map.
> 

Try switching the VC to KD_GRAPHICS mode before you run your app. Then
switch it back to KD_TEXT on exit, ie:

fd = open("/dev/tty0", FLAG);
ioctl(fd, KDSETMODE, KD_GRAPHICS);

Let me know if doing the above still writes the console palette to the
cmap. That will be a bug.

Tony

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs.FB_VISUAL_DIRECTCOLOR

[James L. <ja...@ak...>]

Awesome!

Thanks so much!

I still have some tweaking to do, but I now have code that works for ATI,
Nvidia and several others (DIRECTCOLOR). Before it really only worked well
with Matrox (TRUECOLOR).

The first thing that I notice is that if I run fbset before any of my code
and set the fb to be 32 bits per pixel, then my code, at 32 bpp, looks
perfect.

But if I leave the fb at 8 bpp and my code changes the bpp at runtime to 32,
it looks like the first 16 console colors have been written into the color
map.

No matter what, I'm successfully putting a picture into video cards that I
had no luck with before!

Thanks again!      James.    :o)



----- Original Message ----- 
From: "Antonino A. Daplas" <ad...@gm...>
To: "Antonino A. Daplas" <ad...@gm...>
Cc: "James Lehman" <ja...@ak...>;
<lin...@li...>
Sent: Saturday, August 05, 2006 8:02 PM
Subject: Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR
vs.FB_VISUAL_DIRECTCOLOR


> Antonino A. Daplas wrote:
> > James Lehman wrote:
> >> Can someone please explain the difference between these two display
types?
> >>
> >> FB_VISUAL_TRUECOLOR
> >> FB_VISUAL_DIRECTCOLOR
> >>
> >> My frame buffer API, ezfb, works well with cards that are
> >> FB_VISUAL_TRUECOLOR, but not so well with cards that are
> >> FB_VISUAL_DIRECTCOLOR.
> >>
> >> http://www.akrobiz.com/ezfb/
> >
> > Truecolor:
> >
> > pixel = red << offset | green << offset | blue << offset | alpha <<
offset;
> >
> > where red, green, blue, alpha are the actual values of each pixel
component
> >
> > Directcolor:
> >
> > pixel = red_index << offset | green_index << offset |
> > blue_index << offset | alpha_index << offset;
> >
> > where *_index's are the index to the Hardware LUT, ie:
> >
> > red = red_map[red_index];
> >
> > Thusly:  In Directcolor, you have to initialize the LUT first, by
> > sending an FBIOPUTCMAP ioctl. If you want Directcolor to behave like
> > Truecolor, then send a linear colormap where:
> >
> > {red|green|blue|alpha}_map[i] = i;
>
> One more note, the above is fine if each color component is 8-bits in
> size (RGB888, for instance), but for RGB555, you have
> to downscale. So the untested code below will work better:
>
> red_map[i/(1 << (8 - red_length))] = i;
> red_map[i/(1 << (8 - 5))] = i;
> red_map[i/8] = i;
>
> Tony
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Linux-fbdev-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users
>

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs. FB_VISUAL_DIRECTCOLOR

[Antonino A. D. <ad...@gm...>]

Antonino A. Daplas wrote:
> James Lehman wrote:
>> Can someone please explain the difference between these two display types?
>>
>> FB_VISUAL_TRUECOLOR
>> FB_VISUAL_DIRECTCOLOR
>>
>> My frame buffer API, ezfb, works well with cards that are
>> FB_VISUAL_TRUECOLOR, but not so well with cards that are
>> FB_VISUAL_DIRECTCOLOR.
>>
>> http://www.akrobiz.com/ezfb/
> 
> Truecolor:
> 
> pixel = red << offset | green << offset | blue << offset | alpha << offset;
> 
> where red, green, blue, alpha are the actual values of each pixel component
> 
> Directcolor:
> 
> pixel = red_index << offset | green_index << offset |
> 	blue_index << offset | alpha_index << offset;
> 
> where *_index's are the index to the Hardware LUT, ie:
> 
> red = red_map[red_index];
> 
> Thusly:  In Directcolor, you have to initialize the LUT first, by
> sending an FBIOPUTCMAP ioctl. If you want Directcolor to behave like
> Truecolor, then send a linear colormap where:
> 
> {red|green|blue|alpha}_map[i] = i;

One more note, the above is fine if each color component is 8-bits in
size (RGB888, for instance), but for RGB555, you have
to downscale. So the untested code below will work better:

red_map[i/(1 << (8 - red_length))] = i;
red_map[i/(1 << (8 - 5))] = i;
red_map[i/8] = i;

Tony

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs. FB_VISUAL_DIRECTCOLOR

[Antonino A. D. <ad...@gm...>]

Antonino A. Daplas wrote:
> James Lehman wrote:
>> Can someone please explain the difference between these two display types?
>>
>> FB_VISUAL_TRUECOLOR
>> FB_VISUAL_DIRECTCOLOR
>>
>> My frame buffer API, ezfb, works well with cards that are
>> FB_VISUAL_TRUECOLOR, but not so well with cards that are
>> FB_VISUAL_DIRECTCOLOR.
>>
>> http://www.akrobiz.com/ezfb/
> 

> i = red;
> red <<= 8;
> red_map[i] = red;

Wrong pseudocode, should be:

i = red;
red |= red << 8;
red_map[i] = red;

Tony
 

Re: [Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs. FB_VISUAL_DIRECTCOLOR

[Antonino A. D. <ad...@gm...>]

James Lehman wrote:
> Can someone please explain the difference between these two display types?
> 
> FB_VISUAL_TRUECOLOR
> FB_VISUAL_DIRECTCOLOR
> 
> My frame buffer API, ezfb, works well with cards that are
> FB_VISUAL_TRUECOLOR, but not so well with cards that are
> FB_VISUAL_DIRECTCOLOR.
> 
> http://www.akrobiz.com/ezfb/

Truecolor:

pixel = red << offset | green << offset | blue << offset | alpha << offset;

where red, green, blue, alpha are the actual values of each pixel component

Directcolor:

pixel = red_index << offset | green_index << offset |
	blue_index << offset | alpha_index << offset;

where *_index's are the index to the Hardware LUT, ie:

red = red_map[red_index];

Thusly:  In Directcolor, you have to initialize the LUT first, by
sending an FBIOPUTCMAP ioctl. If you want Directcolor to behave like
Truecolor, then send a linear colormap where:

{red|green|blue|alpha}_map[i] = i;

In Truecolor, the color map need not be initialized.

Tony

Note: Each color component in struct fb_cmap are u16 in size, so the
contents of the cmap must be duplicated in both bytes, ie:

i = red;
red <<= 8;
red_map[i] = red;

[Linux-fbdev-users] FB_VISUAL_TRUECOLOR vs. FB_VISUAL_DIRECTCOLOR

[James L. <ja...@ak...>]

Can someone please explain the difference between these two display types?

FB_VISUAL_TRUECOLOR
FB_VISUAL_DIRECTCOLOR

My frame buffer API, ezfb, works well with cards that are
FB_VISUAL_TRUECOLOR, but not so well with cards that are
FB_VISUAL_DIRECTCOLOR.

http://www.akrobiz.com/ezfb/

Thanks!           James.   :o)

Re: [Linux-fbdev-users] radeonfb 15Khz

[Antonino A. D. <ad...@gm...>]

Diego CLAEYS wrote:
> Hi,
> 
> I would like to compile radeonfb in my kernel but with specific timings as
> default in order to support a 15Khz arcade monitor.
> 
> In other words I would like to do this but compiled in the kernel :
> 
> modprobe radeonfb
> fbset -g 640 248 640 496 16 -t 69259 136 72 17 0 64 2
> 
> Can you help me or tell me who can help.
> Many thanks in advance.
> 

Open drivers/video/modedb.c, then add your timings to

static const struct fb_videomode modedb[]

Boot with video=radeonfb:640x248.

Tony

[Linux-fbdev-users] radeonfb 15Khz

[Diego C. <die...@gm...>]

Hi,

I would like to compile radeonfb in my kernel but with specific timings as
default in order to support a 15Khz arcade monitor.

In other words I would like to do this but compiled in the kernel :

modprobe radeonfb
fbset -g 640 248 640 496 16 -t 69259 136 72 17 0 64 2

Can you help me or tell me who can help.
Many thanks in advance.

[Linux-fbdev-users] How to determine the console attached to a given fbdev

[Sean D'E. <se...@de...>]

I have implemented vt switching in my program, I can set up the program
to recieve signals if the vt it is attached to is aquired or
released using linux-kbd ioctls.

This would be enough if I did not have two monitors and two framebuffer
devices!  I want my program to be able to update if it is still the most
recently active vt on it's fbdev.

Right now I continuously poll ioctl on CON2FB while I do not have the
active vt, and supply the active vt number which I get from another ioctl.
If the resulting framebuffer matches mine, I know I need to stop drawing.

This is not a good solution, sometimes I need to refresh the display when
switching because of this.

Would anything need to be implemented in kernel space to allow for this? 


Thanks

[Linux-fbdev-users] linux-fbdev.org webmaster, admin, or the like

[Jan B. <jan...@gm...>]

Hi,
could you please point me to a person responsible for linux-fbdev.org,
or point said person to me? I tried sending mail to support@ and
webmaster@, but the responsible MX (smtp.secureserver.net) rejected it
with "relaying denied".
regards,
    Jan
-- 
GPG encryption preferred, I'm not on the list.

Re: [Linux-fbdev-users] Frame Buffers on VMware ESX using CentOS

[Petr V. <van...@vc...>]

Rick Thiessen wrote:
> I am working on a project that requires creating PDF's
> with Oracle Forms using Frame Buffers.  We have been 
> doing this on HP-UX but need to move off to a Blade 
> Server group running VMware ESX.  The Instance of VMware
> will be running Redhat Enterprise-4.3 or CentOS-4.3.
> 
> What do I need to setup Frame Buffers under these OS versions?
> What should I look for as far as devices?

You'll have to use VESA framebuffer.  There exists patch for VMware SVGA 
framebuffer, but it was never merged in.  As you are using ESX, you'll 
probably also want to add

svga.vramSize = 16777216

to VM's *.vmx configuration file, so VM has 16MB framebuffer instead of 
default 4MB one - but it depends on resolution and color depth you want 
to use.  Just boot kernel with appropriate vga=XXX argument (f.e. 
vga=773 to get 1024x768/8bpp) and you should be in framebuffer.  You 
probably want to disable rhgb to have full control over this.
							Petr Vandrovec

[Linux-fbdev-users] Frame Buffers on VMware ESX using CentOS

[Rick T. <ri...@or...>]

I am working on a project that requires creating PDF's
with Oracle Forms using Frame Buffers.  We have been 
doing this on HP-UX but need to move off to a Blade 
Server group running VMware ESX.  The Instance of VMware
will be running Redhat Enterprise-4.3 or CentOS-4.3.

What do I need to setup Frame Buffers under these OS versions?
What should I look for as far as devices?

Has anyone done this kind of configuration?

Rick T

Re: [Linux-fbdev-users] fast framebuffer reading

[Nathan K. <nat...@gm...>]

> Nathan King wrote:
> > Hi James,
> >
> > I can mmap it, but I found that using file operations to access it was
> > about 2-3 times faster than accessing it through a mmap'ed buffer. Is
> > it possible I'm doing that wrong? Here's my stuff for that:
> >
>
> Using the file accessors are actually more portable than using mmap. And
> if it's faster, then that's better.
>
> > fbfd = open("/dev/fb0", O_RDONLY);
> > fbp = (unsigned char *)mmap(0, screensize, PROT_READ, MAP_SHARED, fbfd, 0);
> >
> > Then I read from fbp with memcpy and memcmp. If I'm going against some
> > long upheld programming convention feel free to throw things at me.
>
> Looks okay. Reading from video RAM on PCI cards will always be slower than
> writes.
>
> >
> > Thanks,
> > Nathan
> >
> >
> > Your only choices for the standard kernel are mmap and read/write. But
> if you can use an acceleration library (DirectFB www.directfb.org), that
> would be the best.
>
> Tony

This just occurred to me so its probably not possible, but could
something like ShadowFB for X be implemented without X?

Re: [Linux-fbdev-users] Linux-fbdev-users Digest, Vol 1, Issue 332

[Antonino A. D. <ad...@gm...>]

Nathan King wrote:
> Hi James,
> 
> I can mmap it, but I found that using file operations to access it was
> about 2-3 times faster than accessing it through a mmap'ed buffer. Is
> it possible I'm doing that wrong? Here's my stuff for that:
> 

Using the file accessors are actually more portable than using mmap. And
if it's faster, then that's better.

> fbfd = open("/dev/fb0", O_RDONLY);
> fbp = (unsigned char *)mmap(0, screensize, PROT_READ, MAP_SHARED, fbfd, 0);
> 
> Then I read from fbp with memcpy and memcmp. If I'm going against some
> long upheld programming convention feel free to throw things at me.

Looks okay. Reading from video RAM on PCI cards will always be slower than
writes.

> 
> Thanks,
> Nathan
> 
> 
>> On Wed, 2006-06-28 at 18:08 -0600, Nathan King wrote:
>>> What's the preferred way to read a block of pixels from the screen?
>>> I'm developing something like a remote desktop app, and I haven't
>>> found a whole lot of documentation on this. Right now I'm opening
>>> the /dev/fb0 device and accessing it by means of lseek/read, file
>>> descriptor style. This seems reasonably fast but I feel there must be
>>> a better way.

Your only choices for the standard kernel are mmap and read/write. But
if you can use an acceleration library (DirectFB www.directfb.org), that
would be the best.

Tony

Re: [Linux-fbdev-users] Linux-fbdev-users Digest, Vol 1, Issue 332

[Nathan K. <nat...@gm...>]

Hi James,

I can mmap it, but I found that using file operations to access it was
about 2-3 times faster than accessing it through a mmap'ed buffer. Is
it possible I'm doing that wrong? Here's my stuff for that:

fbfd = open("/dev/fb0", O_RDONLY);
fbp = (unsigned char *)mmap(0, screensize, PROT_READ, MAP_SHARED, fbfd, 0);

Then I read from fbp with memcpy and memcmp. If I'm going against some
long upheld programming convention feel free to throw things at me.

Thanks,
Nathan


>
> On Wed, 2006-06-28 at 18:08 -0600, Nathan King wrote:
> > What's the preferred way to read a block of pixels from the screen?
> > I'm developing something like a remote desktop app, and I haven't
> > found a whole lot of documentation on this. Right now I'm opening
> > the /dev/fb0 device and accessing it by means of lseek/read, file
> > descriptor style. This seems reasonably fast but I feel there must be
> > a better way.
>
> Can you mmap /dev/fb0?
>
> Regards,
> James.

Re: [Linux-fbdev-users] fast franebuffer reading and writing

[James S. <jam...@op...>]

On Wed, 2006-06-28 at 18:08 -0600, Nathan King wrote:
> What's the preferred way to read a block of pixels from the screen?
> I'm developing something like a remote desktop app, and I haven't
> found a whole lot of documentation on this. Right now I'm opening
> the /dev/fb0 device and accessing it by means of lseek/read, file
> descriptor style. This seems reasonably fast but I feel there must be
> a better way.

Can you mmap /dev/fb0?

Regards,
James.

[Linux-fbdev-users] fast franebuffer reading and writing

[Nathan K. <nat...@gm...>]

Hey folks,

What's the preferred way to read a block of pixels from the screen? I'm
developing something like a remote desktop app, and I haven't found a whole
lot of documentation on this. Right now I'm opening the /dev/fb0 device and
accessing it by means of lseek/read, file descriptor style. This seems
reasonably fast but I feel there must be a better way. I tried the XShm
memory XLib extension but that was a little slower(and a booger to get
working right). I'd rather not have to go through X anyway. Any suggestions
on where to look? Speed and hardware independence are my two biggest
priorites.

On a slightly related note, when I was screwing with XShm, I got to know a
little about shared memory functions. Can I use these on the Linux
framebuffer instead of X?

Much grass,
Nathan

Re: [Linux-fbdev-users] graphic overlay/mixing question

[Unger R. <ric...@te...>]

Hi!

AFAIK what you want is not that easy - blending between two framebuffers =
is not a function that is part of the standard kernel.

Some hardware and framebuffer driver combinations may present the =
different layers supported by the hardware as separate framebuffer =
interfaces (fb0, fb1). In this case fb0 might be the graphics layer, and =
fb1 might be the videolayer. By setting the right parameters in the =
framebuffer driver it may be possible to blend between the layers.

All this depends completely on the hardware though.

A much better option would be to use something like DirectFB - with this =
library you can mix different layers of graphics and video in a flexible =
way, and it operates accellerated on most common hardware. This option =
would require your software to support DirectFB though, so that may not =
be an option.

Richard


=20

> -----Urspr=FCngliche Nachricht-----
> Von: lin...@li...=20
> [mailto:lin...@li...] Im=20
> Auftrag von Niklas Fondberg
> Gesendet: Dienstag, 27. Juni 2006 16:39
> An: lin...@li...
> Betreff: [Linux-fbdev-users] graphic overlay/mixing question
>=20
> Hi all,
> I have a question that might be off topic but after searching=20
> the net and mailing lists I give in and hope for some help on=20
> this list.
>=20
> I wonder what the best way to mix graphics written to a=20
> framebuffer over decoded video is. I can't change the way the=20
> graphics is written to the device, it has to be directly to a=20
> linux framebuffer device.
>=20
> My hope is that there are some generic way of doing it=20
> without bying a fancy XYZ graphics card but if I must I'll do that.
>=20
> Flow overview:
> userapp -> /dev/fb1
> player -> /dev/fb0
> The graphics would be either with CHROMAKEY transparency=20
> 16bpp or 32 bpp ARGB
>=20
> Kind regards
> Niklas Fondberg
>=20
>=20
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> Linux-fbdev-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users
>=20

[Linux-fbdev-users] graphic overlay/mixing question

[Niklas F. <nik...@ti...>]

Hi all,
I have a question that might be off topic but after searching the net
and mailing lists I give in and hope for some help on this list.

I wonder what the best way to mix graphics written to a framebuffer over
decoded video is. I can't change the way the graphics is written to the
device, it has to be directly to a linux framebuffer device.

My hope is that there are some generic way of doing it without bying a
fancy XYZ graphics card but if I must I'll do that.

Flow overview:
userapp -> /dev/fb1
player -> /dev/fb0
The graphics would be either with CHROMAKEY transparency 16bpp or 32 bpp
ARGB

Kind regards 
Niklas Fondberg