linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Geert U. <ge...@li...>]

On Wed, 12 Feb 2003, James Simmons wrote:
> > > > All comments are welcomed! Thanks!
> > > 
> > > Come on, is there really no one to comment on this??
> > 
> > Except a question why it's not merged yet? :)
> 
> Looking for work has keot me busy. I merged it. One change I did do was 
> changed the CONFIG_FB_LOGO_* to CONFIG_LOGO_. In theory any one can use 
> the logo (i.e newport console). It is a much welcomed improvement. I 

OK.

> removed the hgafb logo code in the latest tree. It should use the standard 
> logo code. Also how should we go about for personal logos. Companies might 
> want to throw in there own thing which I have no issue with.

An option CONFIG_LOGO_USER, and a path CONFIG_LOGO_USER_PATH to a logo? Or
multiple user-specific logos (one of each type)?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[James S. <jsi...@in...>]

> > 1.  Changed meaning of image.depth.  If image.depth == 0, it flags for
> > color expansion, otherwise, it flags for image drawing (without color
> > expansion).  This change is to accomodate monochrome cards so they can
> > differentiate character drawing from logo drawing.
> 
> What's the status of this issue? Monochrome is still broken due to this.

Ug. There are a few issues left to deal with. 

1) The cursor issue. We need to add in the cusor ioctl call for people to 
use. Theortically there should be no issues with using soft_cursor with 
full color images with xxfb_imageblit. I like to see dest go away in 
struct fb_cursor. It's a matter of taking advantage of the upper console 
layer here. We shouldn't have any static variables in accel_cursor because 
if we have multiple cards we have problems. I plan to work on that.

2) Tileblits and stuff. I have been thinking about this and I really like 
to make it even more generic. We also have seperate buffers for textures 
for example which could also be used to draw fonts. The first thing is
allocating or retreiving memory space for where to store the images. 
Second is to draw it. I guess a index of position would be used.

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[James S. <jsi...@in...>]

> > > All comments are welcomed! Thanks!
> > 
> > Come on, is there really no one to comment on this??
> 
> Except a question why it's not merged yet? :)

Looking for work has keot me busy. I merged it. One change I did do was 
changed the CONFIG_FB_LOGO_* to CONFIG_LOGO_. In theory any one can use 
the logo (i.e newport console). It is a much welcomed improvement. I 
removed the hgafb logo code in the latest tree. It should use the standard 
logo code. Also how should we go about for personal logos. Companies might 
want to throw in there own thing which I have no issue with.

[Linux-fbdev-devel] Re: fbcon scrolling madness + fbset corruption

[James S. <jsi...@in...>]

> So it looks like something isn't limiting the yoffset in the generic
> console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> is just nonsense.

I'm going to need to do some heavy cleaning in the next few days.

> I also noticed an additional problem with fbcon: if I change the
> resolution using fbset, the change occurs, except I end up with
> corrupted mess on the screen (the reminents of the original display.)
> The shell prompt is nowhere to be seen.
>
> Hitting ^L clears the screen and then the shell prompt is visiable.

The method to use now is stty to change the console mode. It works :-)
fbset is used to change the variable the vt terminals are not familiar 
with such as bpp.

Re: [Linux-fbdev-devel] Multiple rivafb devices?

[James S. <jsi...@in...>]

> I have two Nvidia cards (one AGP and one PCI) and would like rivafb
> to initialise both. I understand that currently isn't possible?
> 
> Would it be difficult to implement support for multiple cards?

Last time I seen someone do that the low level X driver part blew up. The 
other issue is you have to initialize the second card because the BIOS 
usually only initializes one card.

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[James S. <jsi...@in...>]

> > I wonder if people will like having to build the DRM for a framebuffer
> > device... a solution where one component uses the other if it's there,
> > but works without it otherwise, might be better.
> > 
> Yes, your suggestion is better.  I did browse the dri code, and my
> feeling is drm is coded for userspace clients without any usable hooks
> for clients residing in kernel space. I'm still wondering how to access
> DRM services from kernel space.  

I have to agree. For most platforms fbdev is a needed. You could view DRM 
as a power extenstion to fbdev. Well that is how I view it. If we have DRM 
enabled we can enable more features in fbdev.

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[James S. <jsi...@in...>]

> > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it 
> > works.
> > 
> 
> I haven't tried this yet, but I think it will work.  The only (very
> minor) problem with this is the rivafb's printk output will be incorrect
> (no info on video memory size).  

True. All to keep in sync with X :-( Maybe we should break nv_driver.c 
syncing since it already has been altered. Hell with it. Could you update 
a patch with seperate functions for memsize clock finding.

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[James S. <jsi...@in...>]

> >From what I understand about sysfs, you can only have one type per file,
> so each field will have to be in separate files.  

Correct.

> To synchronize, we can
> perhaps use a file ('sync', 'lock', 'update' or whatever) which is
> similar in function to fb_var_screeninfo.activate. Only when the user
> writes to this file that the new settings are synchronized and we call
> fb_set_var() or whatever.

This doesn't bother me. I cna live with that. Actually it is a good idea 
to do it that way. THis way if we have graphics clients we can invalidate 
them when switch the entire graphics state. The accel engine will switch 
behavior on changing the video mode.

> How do you think sysfs support will be written?  Will this mean that the
> framebuffer system has to register its own kobject as the top level
> entry in sysfs, no?  

I think so. I haven't looked down this aveue yet. This is a latter time 
project.

> This would also mean that we need something similar
> for the console subsystem if it has to support additional features, ie
> rotation?

I'm not to thrilled about this idea.

Re: [Linux-fbdev-devel] [PATCH] Interlace for rivafb driver

[James S. <jsi...@in...>]

> > I applied your direct color patch. The X server has issues without it as 
> > well. For some reason the screen is cut in half and the colors are wrong.
> > Even when I leave X. The only solution is to switch back to 8 bpp mode.
> > 
> 
> I get this too.  For some reason, X fails to dynamically set rivafb to
> the mode it wants to use.  So, I have to use fbset first to set rivafb
> to the mode and visual X is going to use.  After doing this, I get
> XFBdev working nicely (at Depth 15).
> 
> I have no problems with DirectFB though.

Ug. Well the driver is really coming along. This is without specs. 

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[James S. <jsi...@in...>]

> Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
> generic ioctl which can block or send a signal on vertical blank
> interrupts.

Nice :-)

Re: [Linux-fbdev-devel] [2.5.59] radeonfb not working

[James S. <jsi...@in...>]

> If   I  append   a  specific   video  mode   I'll  get   "out  of   scan
> range"   or  "no   signal"  depending   on  the   video  mode. This   is
> "video=radeon:640x480-16@85" (no signal):

Ug. The default mode in the modeb must be not supported by your card. Can 
you try lowering the value for 85.

Re: [Linux-fbdev-devel] Framebuffer overflow halts network (fwd)

[James S. <jsi...@in...>]

> Sorry to bother you "privately", but I can't find much info of the use of
> framebuffer after it is installed.
> 
> I have set up my primary work machine (i.e. it is mostly used as a terminal
> to connect to other servers) with framebuffer and have 64 lines*160 chars in
> a pretty font.
> 
> I ssh to other servers from this machine.
> 
> If I do something which create a lot of output, eg. ls -lR /, the remote
> machine sends more data than the framebuffer-terminal can handle. This
> blocks the network on the terminal machine, which also is nameserver,
> internal webserver and upsd server.
> 
> Is it possible to set up some sort of flow control, so the remote machine
> stops when the terminal is overloaded?
> 
> Both servers are 100Mb, on different switches, which are connected at 100Mb
> The terminal is on a Cisco, the other on a cheaper 24ports switch.
> 
> If you can't help me, can you direct me in the proper direction?

Which kernel are you using and whcih video card?

Re: [Linux-fbdev-devel] [PATCH] Fix for wasted memory in rivafb?

[James S. <jsi...@in...>]

> This patch fixes a problem with wasted memory in the rivafb driver.
> For some reason, only half the memory is currently allowed when 
> maximizing the virtual screen. The 2.5.x tree has the same problem.
> 
> Is this a reserve for something? I have not found any use for it 
> inside the driver.

I tried it out. It messed up my screen. I really wished I had the specs.
It would make life easier.

[Linux-fbdev-devel] aty128fb patch

[Jon S. <jon...@ya...>]

This patch against current 2.5 does four things:

1) Enables framebuffer for my Rage128 AIW. 
2) Changed the way the boot ROM is located. Instead of
searching at C000 it just asks the card where the ROM
is. This allows the Rage128 to be used as a secondary
video adapter.
3) Made the error handling when the card was inited
work correctly.
4) Fixed some IFDEFs so that if the driver is compiled
for UML you don't get syntax errors.

Note that if you want to use the card as a secondary
adapter you still need to run a user mode program like
vbios.vm86 to reset it before use.  I have been
unsuccessful in getting ATI to tell me how to reset
the card directly from a protected mode device driver.

I also wanted to add protected mode DDC support but
again I can't get the needed info from ATI.

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Re: [Linux-fbdev-devel] [PATCH] Funny sync calculation correction

[James S. <jsi...@in...>]

Applied.

[Linux-fbdev-devel] Passing the torch [was Re: fbcon scrolling madness + fbset corruption]

[James S. <jsi...@in...>]

> No one's commented on this yet.
> 
> James?

Sorry about the silence. The last month I have been devoting all my time 
to look for work. As of next month I will be out of money. Meaning no home 
to live in thus no internet. Because of this I like to have someone 
replace me. Antonino you have done some really great work. I like you to 
replace me to work with Geert to further the framebuffer layer. I still 
have a month left to live on so I will contribute as much as I can. Thank 
you.

Re: [Linux-fbdev-devel] dead code in fbcon

[James S. <jsi...@in...>]

Applied.

> fbcon_changevar() contains some code (copy-and-pasted from
> fbcon_set_display()?) which is never used because save is never set to
> non-NULL.
k

Re: [Linux-fbdev-devel] Radeon 9000 on a linux 2.4.18 kernel.

[Sven L. <lu...@dp...>]

On Fri, Jan 24, 2003 at 11:09:46AM -0800, Ani Joshi wrote:
> 
> Try patching your 2.4.18 with
> 
> http://gate.crashing.org/~ajoshi/radeonfb-0.1.6.diff.gz
> 
> (I forget which kernel I made this diff against, but it shouldn't complain
> much.)

It is a diff against 2.4.20, but i managed to apply the needed changes
from 2.4.18->2.4.19->2.4.20, so it didn't complain much. Still, there
were some stuff missing, but i think i got it right.

Anyway i built the kernel and launched it, it now recognize my radeon
9000, but my DVI connected monitor complains about wrong timings (it say
18,5KHz & 23Hz, which is not supported by the monitor). Anyway, here is
the relevant output :

radeonfb: ref_clk=2700, ref_div=12, xclk=25000 defaults
radeonfb: detected DFP panel size from registers: 1024x768
Console: switching to colour frame buffer device 80x30
radeonfb: ATI Radeon 9000 If DDR SGRAM 64 MB
radeonfb: DVI port DFP monitor connected
radeonfb: CRT port no monitor connected

Tell me if another part of the log is needed.

I will try connecting a analog monitor and see what happens.

Friendly,

Sven Luther

[Linux-fbdev-devel] dead code in fbcon

[Geert U. <ge...@li...>]

fbcon_changevar() contains some code (copy-and-pasted from
fbcon_set_display()?) which is never used because save is never set to
non-NULL.

--- linux-2.5.59/drivers/video/console/fbcon.c	Fri Jan 17 12:09:27 2003
+++ linux-geert-2.5.59/fbcon.c	Mon Feb 10 10:19:58 2003
@@ -766,7 +766,6 @@
 		struct vc_data *vc = p->conp;
 		int nr_rows, nr_cols;
 		int old_rows, old_cols;
-		unsigned short *save = NULL, *q;
 		int i, charcnt = 256;
 		struct font_desc *font;
 
@@ -846,15 +845,6 @@
 		 	vt_cons[vc->vc_num]->vc_mode == KD_TEXT) {
 			accel_clear_margins(vc, p, 0);
 			update_screen(con);
-		}
-		if (save) {
-			q = (unsigned short *) (vc->vc_origin +
-						vc->vc_size_row *
-						old_rows);
-			scr_memcpyw(q, save, logo_lines * nr_cols * 2);
-			vc->vc_y += logo_lines;
-			vc->vc_pos += logo_lines * vc->vc_size_row;
-			kfree(save);
 		}
 
 		if (con == fg_console && softback_buf) {

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] (no subject)

[Antonino D. <ad...@po...>]

On Thu, 2003-02-06 at 23:27, p.g...@li... wrote:
> Hi,
> I have a problem when I change the bpp value, here is the code:
> 
> if( ioctl(fbd, FBIOGET_VSCREENINFO, &var_info) == -1){
> 	perror("\nError IOCTL 1");
> 	exit(0);
> }           
> printf("\n bpp: %d", var_info.bits_per_pixel);   // output is  bpp: 16
> var_info.bits_per_pixel = 24;
> if( ioctl(fbd, FBIOPUT_VSCREENINFO, &var_info) == -1){
> 	perror("\nError IOCTL 2");
> 	exit(0);
> }           
> The program exit with the following message error: 
> Error IOCTL 2: Invalid argument
> 
> How can I set the bpp value? Should I modify the file /etc/X11/XF86Config?

This will depend on the driver you are using.  vesafb does not support
any change to fb_var_screeninfo.  Other drivers, may not round off
invalid values:  ie bpp == 24 is not supported.  Also, increasing bpp
implies that more video memory will be required if var.xres_virtual and
var.yres_virtual remains the same.  So try to check xres, yres,
xres_virtual and yres_virtual against fix.smem_len and
var.bits_per_pixel.  

fix.smem_len >= (var.bits_per_pixel * var.xres_virtual)/8 *
var.yres_virtual.

/etc/X11/XF86Config has nothing to with fbdev.

> 
> I have another problem, I try to write a simple program that reads frame from framebuffer and then creates a Divx file of a few seconds.
> I map the framebuffer to a buffer, but the program crash with a segmentation fault:
>                                                  
>     screen_buffer = (char *)malloc(DIM_BUFFER * sizeof(char));

you don't need this step.

>     screen_buffer = (void *)mmap(0, DIM_BUFFER, PROT_READ, MAP_SHARED, fbd, 0);                 

check if mmap failed, (returns -1).
> 	
>     encFrame.image = (void *)screen_buffer;  <--- causes seg fault

memcpy(encFrame.image, screen_bufer, DIM_BUFFER) is a more appropriate
step to get the contents.

Tony

[Linux-fbdev-devel] (no subject)

[=?iso-8859-1?Q?<p.g...@li...>]

Hi,=0D=0AI have a problem when I change the bpp value, here is the code:=0D=
=0A=0D=0Aif( ioctl(fbd, FBIOGET_VSCREENINFO, &var_info) =3D=3D -1){=0D=0A=
	perror("\nError IOCTL 1");=0D=0A	exit(0);=0D=0A}           =0D=0Aprintf(=
"\n bpp: %d", var_info.bits_per_pixel);   // output is  bpp: 16=0D=0Avar_=
info.bits_per_pixel =3D 24;=0D=0Aif( ioctl(fbd, FBIOPUT_VSCREENINFO, &var=
_info) =3D=3D -1){=0D=0A	perror("\nError IOCTL 2");=0D=0A	exit(0);=0D=0A}=
           =0D=0AThe program exit with the following message error: =0D=0A=
Error IOCTL 2: Invalid argument=0D=0A=0D=0AHow can I set the bpp value? S=
hould I modify the file /etc/X11/XF86Config?=0D=0A=0D=0AI have another pr=
oblem, I try to write a simple program that reads frame from framebuffer =
and then creates a Divx file of a few seconds.=0D=0AI map the framebuffer=
 to a buffer, but the program crash with a segmentation fault:=0D=0A     =
                                            =0D=0A    screen_buffer =3D (=
char *)malloc(DIM_BUFFER * sizeof(char));=0D=0A    screen_buffer =3D (voi=
d *)mmap(0, DIM_BUFFER, PROT_READ, MAP_SHARED, fbd, 0);                 =0D=
=0A	=0D=0A    encFrame.image =3D (void *)screen_buffer;  <--- causes seg =
fault=0D=0A=0D=0AWhat's wrong?  =0D=0A=0D=0AThanks,=0D=0APaolo Gilardetti=
=0D=0A	 =0D=0A

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Antonino D. <ad...@po...>]

On Thu, 2003-02-06 at 17:19, Geert Uytterhoeven wrote:
> 
> I always see the logo twice. The first time it's erased by the text (because
> initially fbcon thinks logo_height = 0), the second time it's displayed
> correctly.
> 
> So I also wondered why it's drawn twice?

I was expecting this behavior because I remember you mentioning it in
one of your early mails.  In my case, it was only drawn once which
lasted only for a blink.

> > Overall, I like it, though it does add some kilobytes to the kernel
> > image size.
> 
> Why would it increase kernel size that much? The logos were there before as
> well (unless you enable all of them, of course :-).
> 
My fault, I accidentally enabled ACPI :-)

Tony

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Geert U. <ge...@li...>]

On 5 Feb 2003, Torrey Hoffman wrote:
> Other options that might be useful, but less important: 
> - Single logo option for SMP
> - A "no logo" option, while still including framebuffer support

FB_LOGO=n?

This still includes the logo code (not the images), but that can be fixed.

> - Logo positioning (centered horizontally, vertically, both)
> - Background and foreground text color options.  
> 
> A combination of these features would make it possible to do a smaller
> logo (say, 256 x 128) centered on the screen with a matching background
> color that would make it look like a full-screen logo, while not
> bloating the kernel image much.

Just two extra fields in fb_logo.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Geert U. <ge...@li...>]

On 5 Feb 2003, Antonino Daplas wrote:
> On Wed, 2003-02-05 at 20:37, Geert Uytterhoeven wrote:
> > Come on, is there really no one to comment on this??
> 
> Actually, I tried the patch before, but it was erased so fast that I
> never got to see the logo :-)
> 
> Anyway, I think it's because logo_lines require logo_height in
> fbcon_set_display().  logo_height is returned by fb_show_logo(), however
> fb_show_logo() is called after computing logo_lines.

I always see the logo twice. The first time it's erased by the text (because
initially fbcon thinks logo_height = 0), the second time it's displayed
correctly.

So I also wondered why it's drawn twice?

> So, how about breaking up fb_show_logo() into fb_prepare_logo() and
> fb_show_logo()?  We can call fb_prepare_logo() to get the logo height
> for the logo_lines, then do an fb_show_logo() for the actual drawing.

OK for me.

> Overall, I like it, though it does add some kilobytes to the kernel
> image size.

Why would it increase kernel size that much? The logos were there before as
well (unless you enable all of them, of course :-).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] [PATCH][FBDEV]: generic fb console rotation infrastructure

[Antonino D. <ad...@po...>]

Hi James,

I decided to add the Console rotation patch which I submitted before to
linux-2.5.59.  The orientation of the display is determined by the
valued of display.rotate, and the appropriate drawing functions in
display.dispsw.  If the display is rotated, fontdata will be prerotated,
and the appropriate console window dimenstions are swapped if necessary.

Currently, this is just an implementation and no hooks are provided yet
to enable/disable this.  This will require some coordination between the
console layer and fbdev.

Current limitations:

1.  cannot support a fontwidth not a multiple of 8 if rotated 180
degrees, and a fontheight not a multiple of 8 if rotated by 90 degrees. 
This is a limitation with fb_imageblit which has no support for bitmap
clipping.

2.  code for panning when rotated by 90 degrees is still buggy, so it's
disabled.

3.  minor graphics glitches.

4.  no support for hardware based rotation, but this should be easy to
add

You can test this by defining DEBUG_ROTATE in the following code
snippet:

#undef DEBUG_ROTATE
#ifdef DEBUG_ROTATE
	/*
	 * change to the appropriate orientation and 
	 * drawing function to test for rotation
	 */
	p->dispsw = &fbcon_180_dispsw;
	p->rotate = FB_VMODE_ROTATE_180
	if (p->rotate) 
		fbcon_rotate_fontdata(p->rotate, p); 
#endif

I've tested the code with several drivers including vga16fb and vesafb.

The patch is at
http://i810fb.sourceforge.net/linux-2.5.59-rotate.diff.gz


Any comments welcome.

Tony