All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Dänzer <daenzerm@student.ethz.ch>
To: "W. Taylor Holliday" <wtholliday@ucdavis.edu>
Cc: Kostas Gewrgiou <gewrgiou@imbc.gr>, linuxppc-dev@lists.linuxppc.org
Subject: Re: XFree 4.0 dual monitor on AGP G4
Date: Fri, 28 Apr 2000 08:09:47 +0200	[thread overview]
Message-ID: <39092B2B.249FFC07@student.ethz.ch> (raw)
In-Reply-To: 200004280051.RAA20647@pop3.ucdavis.edu


"W. Taylor Holliday" wrote:
>
> >
> >  Yes it would work, there is a problem with the approach taken by
> > fbdev/glint, the BusID info isn't used at all there for the choise
> > of the device to be opened, without the fbdev option you always
> > get /dev/fb0 which might not be what you want.
>
> According to the XFree 4 documentation, the BusID determines the device, and
> thus the framebuffer used, even in the case of fbdev. So I'm kinda confused.

This doesn't apply to framebuffer devices, I guess it's about the PCI devices.
There's currently no safe way to find the corresponding fbdev for a given PCI
device and vice versa. But it's being worked on.


> > Here is a small patch (untested) that changes r128 to use the "fbdev"
> > option instead of using BusID to get the fbdev device.
> > If the BusID and fbdev options don't match bad things will happen
> > so be carefull there.
> > For people that don't have more than one r128 card the previous behaviour
> > works better so don't use it...
>
> If I apply your patch and recompile, how should I modify the config file?
> Get rid of all BusID's? Just for the second monitor?

I suggest always giving all BusIDs, it doesn't hurt as long as BusID and fbdev
match.


Michel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2000-04-28  6:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-28  0:51 XFree 4.0 dual monitor on AGP G4 W. Taylor Holliday
2000-04-28  6:09 ` Michel Dänzer [this message]
2000-04-28  7:47   ` Michael Schmitz
  -- strict thread matches above, loose matches on Subject: below --
2000-04-28  0:42 W. Taylor Holliday
2000-04-28  6:06 ` Michel Dänzer
2000-04-26 22:54 W. Taylor Holliday
2000-04-27 13:14 ` Geert Uytterhoeven
2000-04-26 19:51 W. Taylor Holliday
2000-04-26 20:05 ` Michael Schmitz
2000-04-26 19:45 W. Taylor Holliday
2000-04-27 11:10 ` Michel Dänzer
2000-04-27 13:35   ` Kostas Gewrgiou
2000-04-27 13:57     ` Kostas Gewrgiou
2000-04-27 15:23     ` Michel Dänzer
2000-04-24  6:16 W. Taylor Holliday
2000-04-25 11:23 ` Michel Dänzer
2000-04-25  9:27   ` W. Taylor Holliday
2000-04-25 16:51     ` Michel Dänzer
2000-04-25 18:30       ` W. Taylor Holliday
2000-04-26 12:26         ` Michel Dänzer
2000-04-26 13:54           ` Kostas Gewrgiou
2000-04-26 14:16             ` Michel Dänzer
2000-04-26 16:53             ` Ryuichi Oikawa
2000-04-26 17:02               ` Michel Dänzer
2000-04-28 16:37                 ` Ryuichi Oikawa
2000-04-25 17:22     ` Michael Schmitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39092B2B.249FFC07@student.ethz.ch \
    --to=daenzerm@student.ethz.ch \
    --cc=gewrgiou@imbc.gr \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=wtholliday@ucdavis.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.