Joel Carnat | 2 Nov 15:17 2009
Picon

openchrome and native Xorg

Hello,

Now that NetBSD natively ships with Xorg, I can't compile x11/xf86-video-openchrome anymore.

Is openchrome going to replace src/external/mit/xorg/server/drivers/xf86-video-via ?

TIA,
    Jo

matthew green | 3 Nov 04:33 2009
Picon

re: openchrome and native Xorg


   Now that NetBSD natively ships with Xorg, I can't compile x11/xf86-video-openchrome anymore.

this happened with xorg-server 1.6.  with the 1.4* shipped with 
netbsd 5.0, you could use via.

   Is openchrome going to replace src/external/mit/xorg/server/drivers/xf86-video-via ?

this should be happening sometime very soon.

.mrg.

Joel Carnat | 8 Nov 13:51 2009
Picon

RE: re: openchrome and native Xorg

Hello,

I've manually compiled openchrome 0.2.904 on 5.99.21. It compiles and runs (quite) fine.
The only issue is that my TV-out output is scrambled.
Full logs are here (if anyone cares ;) : http://atherios.free.fr/OC/

My real problem is that I thought I would go back to 5.0_STABLE and the via(4) driver but it doesn't seem to be
compiled anymore... I checked the xserver package from "NetBSD-daily/netbsd-5/200911020000Z/i386"
and there is neither via nor openchrome driver... It seems to exists in 5.0.1 release though.

Is this a known issue|feature ?
Shouldn't I be using 5.0_STABLE rather than 5.0.1 ?
The thing is I run all my xen domU in 5.0_STABLE and have a compile domU that provides binary packages update
for all those NetBSD box. Using 5.0.1 on my VIA box would require another domU to provide the binary
packages than I compile from WIP.

Where would I find an "official" state and directions for via(4)/openchrome(4)/unichrome drivers ?

TIA,
  Jo

-----Message initial-----
De: matthew green <mrg <at> eterna.com.au>
Envoyé: mar. 03-11-2009 04:41
À: Joel Carnat <joel <at> carnat.net>; 
Cc: tech-x11 <at> netbsd.org; 
Sujet: re: openchrome and native Xorg

>    
>    Now that NetBSD natively ships with Xorg, I can't compile 
(Continue reading)

matthew green | 9 Nov 02:16 2009
Picon

re: openchrome and native Xorg


the via driver is no longer available.  it has not been updated
for newer xorg-server interfaces.  openchrome is supposed to
be replacing it.  if there are bugs in eg, TV out you should
talk directly to the xorg folks about it.

netbsd 5.0* releases will remain with the via driver, but 5.1*
will not ship with it.

if you really need via, you could try porting the older netbsd
5.0 sources to xorg-server 1.6 interfaces, but i'm not overly
familiar with what has changed.

.mrg.

matthew green | 9 Nov 09:00 2009
Picon

many x11 packages updated in -current


hi folks.

i've updated most of the out of date xorg packages.  the ones
remaining mostly depending upon the xext* and friends that moves
around a bunch of headers, and i haven't finished pulling apart
the right way to deal with it yet.

either way, have fun with most things updated.

please send-pr any new problems...

.mrg.

César Catrián Carreño | 14 Nov 20:11 2009

radeon without DRI

Hello,

I have this r200. This is -current 5.99.21. It began to fail DRI time ago:

cetrox <at> core $ pcictl /dev/pci1 list                                                        [15:59:31 - 09-11-14]
001:00:0: ATI Technologies Radeon 8500 QL (VGA display)

but is not detected by Xorg. This card has its BusID defined in xorg.conf:
Section "Device"
        Identifier      "Radeon-Single"
        Driver          "radeon"
        BusID           "PCI:1:0:0"

The log complains about device not configurated and irq not available:
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] failure adding irq handler, there is a device already using that irq
[drm] falling back to irq-free operation
...
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmGetBusid returned ''
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
...
(II) AIGLX: Screen 0 is not DRI2 capable
drmOpenDevice: node name is /dev/dri/card0
(Continue reading)

Michael | 15 Nov 03:26 2009
Picon

Re: radeon without DRI


Hello,

On Nov 14, 2009, at 2:11 PM, César Catrián Carreño wrote:

> I have this r200. This is -current 5.99.21. It began to fail DRI  
> time ago:
>
> cetrox <at> core $ pcictl /dev/pci1  
> list                                                         
> [15:59:31 - 09-11-14]
> 001:00:0: ATI Technologies Radeon 8500 QL (VGA display)

We really need to put that in some prominent place on the website.

> but is not detected by Xorg. This card has its BusID defined in  
> xorg.conf:
> Section "Device"
>        Identifier      "Radeon-Single"
>        Driver          "radeon"
>        BusID           "PCI:1:0:0"

So you're using an xorg.conf for Xorg 1.4 with Xorg 1.6 which grew  
support for what they call 'PCI domains' - support for several  
independent PCI buses. The old NetBSD-specific code would only see  
whatever is visible through /dev/pci0 which is enough for most older  
PCs with only one PCI bus and an AGP slot, but fails in several  
annoying ways on most halfway recent Power Macs ( which have up to  
four PCI buses ), several sparc64 boxes, modern PCs etc.
So, these days the BusID needs to include a Domain ID. Well actually  
(Continue reading)

César Catrián Carreño | 15 Nov 05:28 2009

Re: radeon without DRI

On Sat, 14 Nov 2009 21:26:14 -0500
Michael <macallan <at> netbsd.org> wrote:
> Did you noticedthis:
> > drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> vs,
> > drmOpenByBusid: drmGetBusid reports pci:0001:01:00.0
> ?

Yes, it is noticeable. Please define the new format of BusID in some man
page, drm(4) or xorg.conf(5).

> That's DRM telling you that it didn't find your device in domain 0 but  
> in domain 1.
> So your BusID needs to look like this:
> PCI:1 <at> 1:0:0
> Also, X -configure would have written this BusID ( if you tried that  
> and it didn't that's a bug so please tell me )

X -configure dies, defining BusID as "PCI:1:0:0"
(xorg.conf.new attached),

and by defining BusID as you said (PCI:1 <at> 1:0:0), Xorg shows the wrong
device 01 <at> 00:00:0 as defined (Xorg.0.log-200911150100 attached).

my xorg.conf attached as well.

> have fun
> Michael

Thanks
(Continue reading)

Michael | 16 Nov 01:42 2009
Picon

Re: radeon without DRI


Hello,

On Nov 14, 2009, at 11:28 PM, César Catrián Carreño wrote:

> On Sat, 14 Nov 2009 21:26:14 -0500
> Michael <macallan <at> netbsd.org> wrote:
>> Did you noticedthis:
>>> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
>> vs,
>>> drmOpenByBusid: drmGetBusid reports pci:0001:01:00.0
>> ?
>
> Yes, it is noticeable. Please define the new format of BusID in some  
> man
> page, drm(4) or xorg.conf(5).

Yeah, and pester Xorg to finally document it. We didn't invent it, the  
code has been in there for a decade.

>> That's DRM telling you that it didn't find your device in domain 0  
>> but
>> in domain 1.
>> So your BusID needs to look like this:
>> PCI:1 <at> 1:0:0
>> Also, X -configure would have written this BusID ( if you tried that
>> and it didn't that's a bug so please tell me )
>
> X -configure dies, defining BusID as "PCI:1:0:0"
> (xorg.conf.new attached),
(Continue reading)

Jukka Salmi | 17 Nov 21:38 2009
Picon

Re: Problems after xorg patch to 5.0_STABLE

Hello,

not having followed development, pull-ups etc. for the last two months,
I built a i386 netbsd-5 release today and installed it on my ThinkPad
X40 to see whether the problem described below still exists.  It does,
except that now I see a black 'X' mouse cursor with a white outline on a
black screen after running startx(1).  While the mouse seems to be
working (I can move the cursor), my ~/.xinitrc seems not to be executed,
the screen stays dark, I can't kill the X server using
Ctrl+Alt+Backspace (yes, I've set the "DontZap" option to "false"),
switching to a VT (Ctrl+Alt+Fn) doesn't work, and sending a SIGKILL to
the Xserver leaves the display garbled.  So, more or less the same
problems as before...

When using the vesa(4) driver instead of intel(4), everything works
fine (and slowly...).

Any hints about how to proceed?  Try the latest intel driver (seems to
be 2.9.1 ATM)?  Try with the intel driver used before the Xorg pull-ups
(2.4.0)?  Something else?

Help is appreciated.

TIA, Jukka

Jukka Salmi --> port-i386 (2009-09-21 19:36:50 +0200):
> John D. Baker --> port-i386 (2009-09-20 19:57:30 -0500):
> > I updated my sources this weekend to pick up the xorg patch in 5.0_STABLE
> > and a number of things don't work right.  I've so-far installed on three
> > different i386 platforms w/different video devices.
(Continue reading)


Gmane