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

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

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

On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> On Mon, 25 Oct 2004 the mental interface of
>
> Antonino A. Daplas told:
> > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > Hi all,
> > >
> > > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime.
> > > The mousecursor is black colored on vt's and can be used as a brush to
> > > darken the screen.
> > >
> > > $ /usr/sbin/fbset
> > > mode "1280x854-60"
> > >     # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > >     geometry 1280 854 1280 854 8
> > >     timings 12529 128 16 8 1 112 3
> > >     rgba 8/0,8/0,8/0,0/0
> > > endmode
> > >
> > > $ cat /proc/fb
> > > 0 ATI Radeon NP
> > >
> > > The bootlogo isn`t shown.
> > >
> > > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > > fine.
> > >
> > > Any hints to get back a white mousecursor and a shown bootlogo as in
> > > 2.6.8?
> >
> > See my other mail for the mousecursor.
>

Can you try booting with video=radeonfb:noaccel?

Tony

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Elimar R. <rie...@lx...>]

On Mon, 25 Oct 2004 the mental interface of
Antonino A. Daplas told:

> On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > Hi all,
> >
> > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime. =
The
> > mousecursor is black colored on vt's and can be used as a brush to
> > darken the screen.
> >
> > $ /usr/sbin/fbset
> > mode "1280x854-60"
> >     # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> >     geometry 1280 854 1280 854 8
> >     timings 12529 128 16 8 1 112 3
> >     rgba 8/0,8/0,8/0,0/0
> > endmode
> >
> > $ cat /proc/fb
> > 0 ATI Radeon NP
> >
> > The bootlogo isn`t shown.
> >
> > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > fine.
> >
> > Any hints to get back a white mousecursor and a shown bootlogo as in
> > 2.6.8?
>=20
> See my other mail for the mousecursor.

Can't find the mail?

> As for the bootlogo, is there a space alloted for the logo, or does your
> console start at the very top? can you send the pertinent parts of your
> config?

CONFIG_FB=3Dy
CONFIG_FB_MODE_HELPERS=3Dy

[...]

CONFIG_FB_RADEON=3Dy
CONFIG_FB_RADEON_I2C=3Dy
[...]

CONFIG_DUMMY_CONSOLE=3Dy
CONFIG_FRAMEBUFFER_CONSOLE=3Dy

# Logo configuration
#
CONFIG_LOGO=3Dy
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=3Dy


Ciao

Elimar


--=20
  You cannot propel yourself forward by
  patting yourself on the back.

Re: [Linux-fbdev-users] CT65550 / chipsfb driver status...

[Laurence A. <la...@cl...>]

On Mon, 2004-10-25 at 13:34, Antonino A. Daplas wrote:
> On Monday 25 October 2004 16:34, Laurence Abbott wrote:
> > I'm not totally sure how I work with multiple framebuffer devices: my
> > AGP card gives me two: /dev/fb/0 which works as I'd expect, and
> > /dev/fb/2, which I think may be TV-out, or something, but this one is
> > only VGA16. The ct65550 one appears as /dev/fb/1
> 
> Doing a cat /proc/fb should tell you what drivers are loaded. What kernel
> version are you using?

This is a 2.6.8 kernel. Yes, /proc/fb does give the numbers I said
above. I also have a /proc/fb0 directory with a couple of files in it
(cannot check at the moment) but no /proc/fb1 or /proc/fb2 (could be
related to vesafb-tng?).

> > I'm currently using the vesafb-tng driver (as part of Gentoo) and think
> > that this may be causing some of my problems! If I use:
> >
> > % fbset -fb /dev/fb/1
> >
> > It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
> > Fair enough. If I try to change the depth on that framebuffer, it
> > corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try
> 
> Normal behavior is not to affect /dev/fb0 if the command is explicit
> to /dev/fb1.  So there is a bug somewhere.  (however, this may happen
> if you have 2 drivers for the same physical device, say vga16fb and
> a driver specific driver)

I will try without compiling support for VGA16 so the second FB on my
AGP card is ignored (hopefully!).

> > with the standard vesafb driver tonight to see if that works any better.
> >
> > In the framebuffer HOWTO, it says that you can only run fbset from teh
> > framebuffer itself. Is this the case? Surely that is the whole point of
> > the -fb switch!
> 
> No, you can run fbset anywhere, even within xterm, if you have the guts.
> If there is no -fb, it defaults to /dev/fb0.

This is what I was hoping...

> > Is there a simple command which can be used to restore a framebuffer
> > back to a sane state, rather than having to reboot?
> 
> There are a few drivers that can restore the hardware state, but the answer
> is generally no.  You can try to have > 1 video cards, load each of their
> drivers.  If your console becomes corrupt, you can use con2fbmap to
> move your console to the known working driver.

I have some more testing to do now...

Thanks,

Laz

Re: [Linux-fbdev-users] CT65550 / chipsfb driver status...

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

On Monday 25 October 2004 16:34, Laurence Abbott wrote:
> On Sun, 2004-10-24 at 11:23, Antonino A. Daplas wrote:
> > On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> > > What is the current status of the driver for the Chips and Technologies
> > > 65550 chipset? I can only find mentions of it from a couple of years
> > > back with regard to a new version of the driver (links to that driver
> > > no longer work).
> >
> > There is a chipsfb driver in 2.6 which looks like is properly coded.
>
> Well, to get chipsfb.c to compile on ix86 architecture, I had to remove
> the dependency on PPC in /usr/src/linux/driver/video/Kconfig, and then
> compilation barfed at line 414:
>
>         p->screen_base = __ioremap(addr, 0x200000, _PAGE_NO_CACHE);
>
> because _PAGE_NO_CACHE is only defined for PPC. Looking through fbmem.c
> for the same symbol, I found that for some architectures other than
> ix86:
>
> pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
>
> and for ix86:
>
> pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
>
> Changing _PAGE_NO_CACHE for _PAGE_PCD in chipsfb.c allowed it co compile
> cleanly (not too sure how legitimate this fix is but it seemed to work
> as a quick bodge!).
>
> > > I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> > > graphics card based on the CT65550 chip, and I'm hoping to get this
> > > working as a basic framebuffer device.
> > >
> > > I believe the current driver only works on PPC architecture but with a
> > > bit of tweaking, I managed to compile the chipsfb module on the ix86
> > > machine containing the card.
> > >
> > > Is this ever likely to work?! Is it likely to work with the VESA
> > > driver?
> >
> > Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
> > ct65550 does have the 2.0 version.
>
> After much more fiddling about (and discovering that the connection to
> the monitor is a bit dodgy), I have got a picture on the monitor
> attached to the ct65550 using the above fix to chipsfb.c. However, this
> is only really with X and the chips driver rather than a proper frame
> buffer driver.
>
> I'm not totally sure how I work with multiple framebuffer devices: my
> AGP card gives me two: /dev/fb/0 which works as I'd expect, and
> /dev/fb/2, which I think may be TV-out, or something, but this one is
> only VGA16. The ct65550 one appears as /dev/fb/1.
>

Doing a cat /proc/fb should tell you what drivers are loaded. What kernel
version are you using?

> I'm currently using the vesafb-tng driver (as part of Gentoo) and think
> that this may be causing some of my problems! If I use:
>
> % fbset -fb /dev/fb/1
>
> It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
> Fair enough. If I try to change the depth on that framebuffer, it
> corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try

Normal behavior is not to affect /dev/fb0 if the command is explicit
to /dev/fb1.  So there is a bug somewhere.  (however, this may happen
if you have 2 drivers for the same physical device, say vga16fb and
a driver specific driver)

> with the standard vesafb driver tonight to see if that works any better.
>
> In the framebuffer HOWTO, it says that you can only run fbset from teh
> framebuffer itself. Is this the case? Surely that is the whole point of
> the -fb switch!

No, you can run fbset anywhere, even within xterm, if you have the guts.
If there is no -fb, it defaults to /dev/fb0.

>
> Is there a simple command which can be used to restore a framebuffer
> back to a sane state, rather than having to reboot?

There are a few drivers that can restore the hardware state, but the answer
is generally no.  You can try to have > 1 video cards, load each of their
drivers.  If your console becomes corrupt, you can use con2fbmap to
move your console to the known working driver.

Tony

Re: [Linux-fbdev-users] CT65550 / chipsfb driver status...

[Laurence A. <la...@cl...>]

On Sun, 2004-10-24 at 11:23, Antonino A. Daplas wrote:
> On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> > What is the current status of the driver for the Chips and Technologies
> > 65550 chipset? I can only find mentions of it from a couple of years
> > back with regard to a new version of the driver (links to that driver no
> > longer work).
> 
> There is a chipsfb driver in 2.6 which looks like is properly coded.

Well, to get chipsfb.c to compile on ix86 architecture, I had to remove
the dependency on PPC in /usr/src/linux/driver/video/Kconfig, and then
compilation barfed at line 414:

        p->screen_base = __ioremap(addr, 0x200000, _PAGE_NO_CACHE);

because _PAGE_NO_CACHE is only defined for PPC. Looking through fbmem.c
for the same symbol, I found that for some architectures other than
ix86:

pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;

and for ix86:

pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;

Changing _PAGE_NO_CACHE for _PAGE_PCD in chipsfb.c allowed it co compile
cleanly (not too sure how legitimate this fix is but it seemed to work
as a quick bodge!).

> > I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> > graphics card based on the CT65550 chip, and I'm hoping to get this
> > working as a basic framebuffer device.
> >
> > I believe the current driver only works on PPC architecture but with a
> > bit of tweaking, I managed to compile the chipsfb module on the ix86
> > machine containing the card.
> >
> > Is this ever likely to work?! Is it likely to work with the VESA driver?
> 
> Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
> ct65550 does have the 2.0 version.

After much more fiddling about (and discovering that the connection to
the monitor is a bit dodgy), I have got a picture on the monitor
attached to the ct65550 using the above fix to chipsfb.c. However, this
is only really with X and the chips driver rather than a proper frame
buffer driver.

I'm not totally sure how I work with multiple framebuffer devices: my
AGP card gives me two: /dev/fb/0 which works as I'd expect, and
/dev/fb/2, which I think may be TV-out, or something, but this one is
only VGA16. The ct65550 one appears as /dev/fb/1.

I'm currently using the vesafb-tng driver (as part of Gentoo) and think
that this may be causing some of my problems! If I use:

% fbset -fb /dev/fb/1

It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
Fair enough. If I try to change the depth on that framebuffer, it
corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try
with the standard vesafb driver tonight to see if that works any better.

In the framebuffer HOWTO, it says that you can only run fbset from teh
framebuffer itself. Is this the case? Surely that is the whole point of
the -fb switch!

Is there a simple command which can be used to restore a framebuffer
back to a sane state, rather than having to reboot?

Cheers,

Laz

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

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

On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> Hi all,
>
> I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime. The
> mousecursor is black colored on vt's and can be used as a brush to
> darken the screen.
>
> $ /usr/sbin/fbset
> mode "1280x854-60"
>     # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
>     geometry 1280 854 1280 854 8
>     timings 12529 128 16 8 1 112 3
>     rgba 8/0,8/0,8/0,0/0
> endmode
>
> $ cat /proc/fb
> 0 ATI Radeon NP
>
> The bootlogo isn`t shown.
>
> The same kernel on a i386 box with radeonfb (Radeon 9000) works
> fine.
>
> Any hints to get back a white mousecursor and a shown bootlogo as in
> 2.6.8?

See my other mail for the mousecursor.

As for the bootlogo, is there a space alloted for the logo, or does your
console start at the very top? can you send the pertinent parts of your
config?

Tony

Re: [Linux-fbdev-users] CT65550 / chipsfb driver status...

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

On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> Hi,
>
> What is the current status of the driver for the Chips and Technologies
> 65550 chipset? I can only find mentions of it from a couple of years
> back with regard to a new version of the driver (links to that driver no
> longer work).

There is a chipsfb driver in 2.6 which looks like is properly coded.

>
> I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> graphics card based on the CT65550 chip, and I'm hoping to get this
> working as a basic framebuffer device.
>
> I believe the current driver only works on PPC architecture but with a
> bit of tweaking, I managed to compile the chipsfb module on the ix86
> machine containing the card.
>
> Is this ever likely to work?! Is it likely to work with the VESA driver?

Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
ct65550 does have the 2.0 version.

> At present, I cannot even see the card with lspci, although I'm not
> convinced that it is seated correctly: have yet to check on that.

That's the first thing you need to do, make sure that the device
is detected first.  Then try vesafb.

Tony

[Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Elimar R. <rie...@lx...>]

Hi all,

I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime. The
mousecursor is black colored on vt's and can be used as a brush to
darken the screen.

$ /usr/sbin/fbset
mode "1280x854-60"
    # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
    geometry 1280 854 1280 854 8
    timings 12529 128 16 8 1 112 3
    rgba 8/0,8/0,8/0,0/0
endmode

$ cat /proc/fb
0 ATI Radeon NP

The bootlogo isn`t shown.

The same kernel on a i386 box with radeonfb (Radeon 9000) works
fine.

Any hints to get back a white mousecursor and a shown bootlogo as in
2.6.8?

Thx

Elimar

--=20
  The path to source is always uphill!
                                -unknown-

[Linux-fbdev-users] CT65550 / chipsfb driver status...

[Laurence A. <la...@cl...>]

Hi,

What is the current status of the driver for the Chips and Technologies
65550 chipset? I can only find mentions of it from a couple of years
back with regard to a new version of the driver (links to that driver no
longer work).

I have recently acquired a Keycorp K57 LCD monitor with a dedicated
graphics card based on the CT65550 chip, and I'm hoping to get this
working as a basic framebuffer device.

I believe the current driver only works on PPC architecture but with a
bit of tweaking, I managed to compile the chipsfb module on the ix86
machine containing the card.

Is this ever likely to work?! Is it likely to work with the VESA driver?
At present, I cannot even see the card with lspci, although I'm not
convinced that it is seated correctly: have yet to check on that.

Cheers,

Laz

Re: [Linux-fbdev-users] matroxfb - 2.4.26 - G450 dualhead -

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

On 21 Oct 04 at 14:28, Andreas Burmester wrote:
> As a bridge between my G450 and arcade machine, I have a JPAC
> (http://www.ultimarc.com/jpac.html), which verifies the resolution and
> amplifies the video signal. The JPAC has 3 LEDs indicating the input
> resolution, 31khz, 25khz and 15khz.
> 
> I have specified two fbmodes, one 15khz and one 31khz.
> 
> mode "15khz"
> # D: 5.544 MHz, H: 15.750 kHz, V: 60.115 Hz
> geometry 256 240 256 480 16
> timings 180375 32 32 16 3 32 3
> accel false
> endmode
> 
> The problem is when I set the 15khz mode on fb0 (connected to the
> JPAC) non of the LEDs is on. If I set the 31khz mode on fb0, the 31khz
> LED is on. Could it be possible that the fbset indicates 15khz, but is
> not actually outputting it?

Are you sure you do not want 'laced true' and normal VGA resolution with
525 lines?  Just take your 31kHz resolution, multiply pixclock by 2 and
set laced to true.
 
> Another thing, is that I set much flexible resolutions on fb0 then
> fb1, how come is that? ie. I can't set the 15khz mode on fb1.

Which resolution you cannot set?  fb1 is more restrictive on line
length (must be multiple of 128 or something like that) and supports
only 16/32 bpp.  And it does not support interlaced picture for RGB
output.
                                                    Petr Vandrovec

[Linux-fbdev-users] matroxfb - 2.4.26 - G450 dualhead - 15khz resolution?

[Andreas B. <and...@gm...>]

I'm trying to get my Matrox G450 dualhead to supply two fb consoles,
one (fb1) at normal resolution (31khz) to my normal screen, and one
(fb0) at old arcade resolution (15khz) to my arcade machine.

As a bridge between my G450 and arcade machine, I have a JPAC
(http://www.ultimarc.com/jpac.html), which verifies the resolution and
amplifies the video signal. The JPAC has 3 LEDs indicating the input
resolution, 31khz, 25khz and 15khz.

I have specified two fbmodes, one 15khz and one 31khz.

mode "31khz"
  # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
  geometry 640 480 640 13100 16
  timings 39721 40 24 32 11 96 2
endmode

mode "15khz"
# D: 5.544 MHz, H: 15.750 kHz, V: 60.115 Hz
geometry 256 240 256 480 16
timings 180375 32 32 16 3 32 3
accel false
endmode

The problem is when I set the 15khz mode on fb0 (connected to the
JPAC) non of the LEDs is on. If I set the 31khz mode on fb0, the 31khz
LED is on. Could it be possible that the fbset indicates 15khz, but is
not actually outputting it?

Another thing, is that I set much flexible resolutions on fb0 then
fb1, how come is that? ie. I can't set the 15khz mode on fb1.

Thanks for any help.
-Andreas

[Linux-fbdev-users] (no subject)

[Andreas B. <and...@gm...>]

confirm 400115

[Linux-fbdev-users] Re: [Linux-fbdev-devel] [RFC] Does fbdev need a cursor API for userland?

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

On Sun, 17 Oct 2004 23:47:15 +0800, Antonino A. Daplas
<ad...@ho...> wrote:

> IMO, I believe that the cursor ioctl should just be removed :-)

The merged fbdev/DRM needs hardware cursor support in fbdev but it
doesn't need the fbdev cursor IOCTL. Moving cursor support to fbcon
won't work either. Implementing cursor support in merged fbdev/DRM
probably means a modified API since we have to deal with multiple
heads.

Are there cards still out there with no hardware cursor support?
How many apps use the user space fbdev interface?

Also, a some point I would like to revisit the fbcon/fbdev interface
and reduce the number of fbdev variables fbcon can access but doesn't
use. fbcon shouldn't have direct access to the fb_info struct, there
should be more of an interface there.

-- 
Jon Smirl
jon...@gm...

[Linux-fbdev-users] [RFC] Does fbdev need a cursor API for userland?

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

Hi all,

I'm done with a little clean-up of the fbcon cursor code.  A problem still
remains with the cursor code in fbmem.c:fb_cursor(). This function is
accessible by the user through the FBIO_CURSOR ioctl.  However, just by
looking at it, I think it is broken. 

The question is, do we need to support this ioctl?  Coding for this correctly
is a bit complicated (very similar to coding for a rudimentary overlay).
However, if it's agreed upon to support this ioctl, here's a proposal and
questions for an implementation:

1. Below can be supported by the current cursor code.  Do we need more?

  - 2-color cursor
  - show, move, hide cursor
  - maximum dimensions of 64x64
  - invert and copy ROPs

2. Should fbdev implement a generic version, or should this be available only
to drivers with hardware cursors?

3. Additionally, code must be written for the following:
  - restriction for single use or locking for multiple use
  - save/restore framebuffer contents underlying the cursor (if a 
    software/generic version is supported) 

4. Implementation

A single ioctl is too unwieldy for usage.  It's probably better to split the
ioctl into at least following:

FBIO_CURSOR_ACTIVATE
	- activate/inactivate user-mode cursor.  This will disable/reenable the 
fbcon cursor, load initial data (colormap, image, map), etc.

FBIO_CURSOR_MOVE
	- show, move or hide cursor

FBIO_CURSOR_LOADCMAP
	- change cursor colormap

FBIO_CURSOR_LOADIMAGE
	- change cursor image and mask

IMO, I believe that the cursor ioctl should just be removed :-)

Comments?

Tony

[Linux-fbdev-users] Re: Linux vesafb console directions.

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

On Wed, 13 Oct 2004, cga wrote:
> Sorry to bother you about such a trivial matter. 
> I am trying to get my laptop to display the linux vesafb console at its native
> 1400x1050 resolution. 
> Please direct me to a newsgroup or mailing list where I might be able to find
> some assistance regarding this matter.

Vesafb relies on the BIOS to set the video mode. So unless the BIOS provides a
1400x1050 mode, it won't work.

What graphics chipset do you have? Perhaps you can use one of the native
drivers to get 1400x1050?

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-users] Boot options for radeonfb?

[GeekGrrl <gee...@ge...>]

I tried that, and still no dice. It seems to ignore everything but 
'crt'.... and then gives 1/2 inch tall characters with loss at both sides 
of the screen.

Thanks for the suggestion, though. Right now I am sticking with vesafb for 
when I need the CRT display to be usable, but I'd like not to have to.

Stephanie

On Oct 1, Antonino A. Daplas wrote:

>> append="video=radeon:"
>
> Try video=radeonfb:<options>. Not guaranteed to work, but it's a start.
>
> Tony
>
>
>

[Linux-fbdev-users] Boot options for radeonfb?

[GeekGrrl <gee...@ge...>]

Greetings!

I have just recently begun to try out radeonfb. I have it compiled into my 
2.6.9-rc3 kernel (I need some of the usb improvements, hence rc3).

It works great with my laptop and lcd screen, but I can't get it to adjust 
itself for when I have my CRT plugged in. I can't find any docs under 
Documentation/fb/ for this particular driver.

Laptop: Dell Inspiron 8600
ATI card: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
LCD: I can't find the brand, but it's 16:10 aspect with default 1680x1050 
CRT: Dell P1130 1280x1024@75 max

I have tried to pass parameters at boot through lilo. I do get display on 
the CRT, but it is unuseable.

append="video=radeon:"
It detects my LCD settings and applies them to my CRT display. I only get 
the 'middle' difference between 1680 and 1280 on the horizontal.

append="video=radeon:1280x1050-24@75,crt"
I get fonts so large I can read them across the room... what is displayed 
to the CRT, anyway. Everything is cut off both ends.

append="video=radeon:1280x1050-24@75"
It just completely ignores this and goes with the default 1680x1050-8@60

It is seeing the CRT connection, but seemingly making no adjustments for 
it, and the above commands were guesses on my part, due to lack of 
documentation as to driver options.

fbset -v
mode "1680x1050-60"
     # D: 119.261 MHz, H: 64.816 kHz, V: 60.014 Hz
     geometry 1680 1050 1728 1050 8
     timings 8385 80 48 22 2 32 6
     hsync high
     vsync high
     rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
     Name        : ATI Radeon NP
     Address     : 0xd0000000
     Size        : 134217728
     Type        : PACKED PIXELS
     Visual      : PSEUDOCOLOR
     XPanStep    : 8
     YPanStep    : 1
     YWrapStep   : 0
     LineLength  : 1728
     MMIO Address: 0xfcff0000
     MMIO Size   : 16384
    Accelerator : No
---------------------

relevant dmesg:
<cut off at the top???>
und panel in BIOS table:
   hblank: 160
   hOver_plus: 48
   hSync_width: 32
   vblank: 30
   vOver_plus: 2
   vSync_width: 6
   clock: 11925
Setting up default mode based on panel info
radeonfb: Power Management enabled for Mobility chipsets
hStart = 1728, hEnd = 1760, hTotal = 1840
vStart = 1052, vEnd = 1058, vTotal = 1080
h_total_disp = 0xd100e5    hsync_strt_wid = 0x406ba
v_total_disp = 0x4190437           vsync_strt_wid = 0x6041b
pixclock = 8385
freq = 11926
lvds_gen_cntl: 003cffa6
Console: switching to colour frame buffer device 210x65
radeonfb: ATI Radeon NP  SDR SGRAM 128 MB
radeonfb_pci_register END
...
i2c /dev entries driver
i2c-core: driver dev_driver registered.
i2c_adapter i2c-0: Registered as minor 0
i2c_adapter i2c-1: Registered as minor 1
i2c_adapter i2c-2: Registered as minor 2
i2c_adapter i2c-3: Registered as minor 3
...
agpgart: Detected an Intel 855PM Chipset.
agpgart: Maximum main memory to use for agp memory: 941M
agpgart: AGP aperture is 128M @ 0xe0000000
--------------------

relevant /var/adm/messages:
Sep 30 18:47:26 mobile-1 kernel: radeonfb: Reversed DACs detected
Sep 30 18:47:26 mobile-1 kernel: radeonfb: Reversed TMDS detected
Sep 30 18:47:26 mobile-1 kernel: radeonfb: Monitor 1 type LCD found
Sep 30 18:47:26 mobile-1 kernel: radeonfb: Monitor 2 type CRT found
Sep 30 18:47:26 mobile-1 kernel: radeonfb: EDID probed
Sep 30 18:47:26 mobile-1 kernel: radeondb: BIOS provided dividers will be used
--------------------

relevant /var/adm/syslog
Sep 30 18:47:26 mobile-1 kernel: radeonfb: I2C (port 2) ... not found
Sep 30 18:47:26 mobile-1 kernel: radeonfb: I2C (port 3) ... found CRT 
display
Sep 30 18:47:26 mobile-1 kernel: radeonfb: I2C (port 4) ... not found
Sep 30 18:47:26 mobile-1 kernel: radeonfb: I2C (port 2) ... not found
Sep 30 18:47:26 mobile-1 kernel: radeonfb: I2C (port 4) ... not found
Sep 30 18:47:26 mobile-1 kernel: Non-DDC laptop panel detected
Sep 30 18:47:26 mobile-1 kernel: radeonfb: I2C (port 3) ... found CRT 
display
Sep 30 18:47:26 mobile-1 kernel: radeonfb: panel ID string: 7T774^D154P1
Sep 30 18:47:26 mobile-1 kernel:
Sep 30 18:47:26 mobile-1 kernel: radeonfb: detected LVDS panel size from 
BIOS: 1
680x1050
Sep 30 18:47:26 mobile-1 kernel: BIOS provided panel power delay: 1000
Sep 30 18:47:26 mobile-1 kernel: ref_divider = b
Sep 30 18:47:26 mobile-1 kernel: post_divider = 1
Sep 30 18:47:26 mobile-1 kernel: fbk_divider = 61
Sep 30 18:47:26 mobile-1 kernel: Scanning BIOS table ...
Sep 30 18:47:26 mobile-1 kernel:  320 x 350
Sep 30 18:47:26 mobile-1 kernel:  320 x 400
Sep 30 18:47:26 mobile-1 kernel:  320 x 400
Sep 30 18:47:26 mobile-1 kernel:  320 x 480
Sep 30 18:47:26 mobile-1 kernel:  400 x 600
Sep 30 18:47:26 mobile-1 kernel:  512 x 384
Sep 30 18:47:26 mobile-1 kernel:  640 x 350
Sep 30 18:47:26 mobile-1 kernel:  640 x 400
Sep 30 18:47:26 mobile-1 kernel:  640 x 475
Sep 30 18:47:26 mobile-1 kernel:  640 x 480
Sep 30 18:47:26 mobile-1 kernel:  720 x 480
Sep 30 18:47:26 mobile-1 kernel:  720 x 576
Sep 30 18:47:26 mobile-1 kernel:  800 x 600
Sep 30 18:47:26 mobile-1 kernel:  848 x 480
Sep 30 18:47:26 mobile-1 kernel:  1024 x 768
Sep 30 18:47:26 mobile-1 kernel:  1280 x 1024
Sep 30 18:47:26 mobile-1 kernel:  1280 x 768
Sep 30 18:47:26 mobile-1 kernel:  1280 x 800
Sep 30 18:47:26 mobile-1 kernel:  1680 x 1050
Sep 30 18:47:26 mobile-1 kernel: Found panel in BIOS table:
Sep 30 18:47:26 mobile-1 kernel:   hblank: 160
Sep 30 18:47:26 mobile-1 kernel:   hOver_plus: 48
Sep 30 18:47:26 mobile-1 kernel:   hSync_width: 32
Sep 30 18:47:26 mobile-1 kernel:   vblank: 30
Sep 30 18:47:26 mobile-1 kernel:   vOver_plus: 2
Sep 30 18:47:26 mobile-1 kernel:   vSync_width: 6
Sep 30 18:47:26 mobile-1 kernel:   clock: 11925
Sep 30 18:47:26 mobile-1 kernel: Setting up default mode based on panel info
Sep 30 18:47:26 mobile-1 kernel: radeonfb: Power Management enabled for Mobility chipsets
Sep 30 18:47:26 mobile-1 kernel: hStart = 368, hEnd = 400, hTotal = 480
Sep 30 18:47:26 mobile-1 kernel: vStart = 202, vEnd = 208, vTotal = 230
Sep 30 18:47:26 mobile-1 kernel: h_total_disp = 0x27003b	hsync_strt_wid = 0x4016a
Sep 30 18:47:26 mobile-1 kernel: v_total_disp = 0xc700e5	vsync_strt_wid = 0x600c9
Sep 30 18:47:26 mobile-1 kernel: pixclock = 8385
Sep 30 18:47:26 mobile-1 kernel: freq = 11926
Sep 30 18:47:26 mobile-1 kernel: lvds_gen_cntl: 003cffa6
Sep 30 18:47:26 mobile-1 kernel: Console: switching to colour frame buffer 
device 40x25
Sep 30 18:47:26 mobile-1 kernel: radeonfb: ATI Radeon NP  SDR SGRAM 128 MB
Sep 30 18:47:26 mobile-1 kernel: radeonfb_pci_register END

So... any clues? Please?

Thanks for your time,
Stephanie

[Linux-fbdev-users] =?iso-8859-1?Q?Re:_i865G_framebuffer?=

[=?iso-8859-1?Q?<syl...@wo...>]

  Hi,=0D=0A=0D=0A  I also ported the intelfb driver to the kernel 2.6. I =
made=0D=0Asome improvements, first enabling acceleration on i845G (my=0D=0A=
chipset, i hope i didn't break i865G support :-) ). And i=0D=0Aalso imple=
mented the support for TV-Out functionality with a=0D=0Adriver for the Ch=
rontel CH7011 TV encoder chip.=0D=0A   I have to polish it and i think i'=
ll can send the code=0D=0Afor the end of this week.=0D=0A=0D=0A  But, to =
return on the subject of this thread, there (still=0D=0A?) are no hardwar=
e support in intelfb for rotation, so i=0D=0Athink it will be slow.=0D=0A=
=0D=0ASylvain=0D=0A=0A=0A************************ ADSL ILLIMITE TISCALI +=
 TELEPHONE GRATUIT ************************ =0ASurfez 40 fois plus vite p=
our 30EUR/mois seulement !  Et t=E9l=E9phonez partout en France gratuitem=
ent,  =0Avers les postes fixes (hors num=E9ros sp=E9ciaux). Tarifs tr=E8s=
 avantageux vers les mobiles et l'international !=0APour profiter de cett=
e offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl  (v=
oir conditions sur le site)=0A

Re: [Linux-fbdev-users] Framebuffer driver for i865

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

On Tuesday 28 September 2004 22:30, fee...@li... wrote:
> Christ Allain (nt...@fr...) has submitted this feedback
>
> Could i use the i810 driver for a i865 system ?

No.

>
> Which kernel supports the i865 ?

Recent 2.4 kernels, using intelfb. You can also use vesafb.

Tony  

[Linux-fbdev-users] Framebuffer driver for i865

[<fee...@li...>]

Christ Allain (nt...@fr...) has submitted this feedback

Could i use the i810 driver for a i865 system ?

Which kernel supports the i865 ?

Thx

Re: [Linux-fbdev-users] Frame buffer detection

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

On Friday 03 September 2004 23:09, ro...@ub... wrote:
> Hello.
>
> How can I determine whether a script is being run
> from a frame buffer console?
>
> I need this information in order to choose the
> correct arguments when calling a program from
> my script.
>

You can parse /proc/fb to find out if any framebuffer drivers are loaded, then 
do an ioctl where request is FBIO_GET_CON2FBMAP, and struct  
fb_con2fbmap.console is set to the console number you want to determine.
If successful, check fb_con2fbmap.framebuffer on return. Valid values are from 
0  to (FB_MAX - 1) where FB_MAX is the number of framebuffer drivers 
configured in your system

In 2.6, an unmapped console will return fb_con2fbmap.framebuffer = -1.  In 
2.4, I'm not sure, but it's possible that it can be undefined.

Tony

[Linux-fbdev-users] Frame buffer detection

[<ro...@ub...>]

Hello.

How can I determine whether a script is being run
from a frame buffer console?

I need this information in order to choose the
correct arguments when calling a program from
my script.

Regards.

Romildo

Re: [Linux-fbdev-users] Radeon (kernel 2.6.7) doesn't show the correct resolution

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

On Mon, 30 Aug 2004, Otto Wyss wrote:
> BTW does anyone know how fbset show the noaccel settings?

| # fbset -accel off
| # fbset
|
| mode "1024x768-75"
|     # D: 78.802 MHz, H: 60.063 kHz, V: 75.078 Hz
|     geometry 1024 768 1024 768 8
|     timings 12690 176 16 28 1 96 3
|     hsync high
|     vsync high
|     rgba 8/0,8/0,8/0,0/0
| endmode
|
| # fbset -accel on
| # fbset
|
| mode "1024x768-75"
|     # D: 78.802 MHz, H: 60.063 kHz, V: 75.078 Hz
|     geometry 1024 768 1024 768 8
|     timings 12690 176 16 28 1 96 3
|     hsync high
|     vsync high
|     accel true
|     rgba 8/0,8/0,8/0,0/0
| endmode
|
| #

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-users] Radeon (kernel 2.6.7) doesn't show the correct resolution

[Otto W. <ott...@or...>]

Otto Wyss wrote:
> 
> 2.6 kernel. Of course a patch which solves my problems would be much better.
> 
Does anyone know the correct syntax for "noaccel" option in module.conf?
In my module.conf there is

options radeonfb noaccel

BTW does anyone know how fbset show the noaccel settings?

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: [Linux-fbdev-users] i865G framebuffer

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

On Monday 30 August 2004 03:01, - wrote:
> I am using i865G and 2.6 kernel series and I would like to use pivot. (Use
> my monitor in portrait.) It seems the options available are quite thin for
> me:
>
> - Xrandr rotation doesn't generally work on Linux platform
> - i810fb doesn't recognize my i865G
> - intelfb hasn't been ported to 2.6 series
> - Intel's version of the driver doesn't support rotation
> - VesaFB. Works.
>
> VesaFB works alright as long as I don't rotate the view. When I rotate the
> performance turns (understandably) completely horrible. 1280x1024x16
> rotated CCW is extremely slow and practically not usable at all.
>
> Is there or will there be any sorts of development that will remedy the
> situation?

I don't have hardware for i830 chipsets and above.  I did made an initial port of
intelfb for 2.6.  

Note that display rotation will require some kind of hardware support in order to
have optimal performance.  This means that even if intelfb is ported to 2.6, the
performance you'll get will not be significantly faster than if you use vesafb.

Basically, you need the Xorg/XFree86 to support rotation for i865.

Anyway, if you are interested, I'm attaching the patch which ports intelfb to 2.6.
It is completely untested, and console acceleration is not included.

Tony