headers
Joel Carnat | 2 Nov 2009 15:17
Favicon
Gravatar

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
Permalink | Reply | 3 comments |
headers
matthew green | 3 Nov 2009 04:33
Picon
Favicon

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.
Permalink | Reply | 2 comments |
headers
Joel Carnat | 8 Nov 2009 13:51
Favicon
Gravatar

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)

Permalink | Reply | 1 comment |
headers
matthew green | 9 Nov 2009 02:16
Picon
Favicon

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.
Permalink | Reply | 0 comments |
headers
matthew green | 9 Nov 2009 09:00
Picon
Favicon

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.
Permalink | Reply | 0 comments |
headers
César Catrián Carreño | 14 Nov 2009 20:11

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)

Permalink | Reply | 3 comments |
headers
Michael | 15 Nov 2009 03:26
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)

Permalink | Reply | 2 comments |
headers
César Catrián Carreño | 15 Nov 2009 05:28

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)

Permalink | Reply | 1 comment |
headers
Michael | 16 Nov 2009 01:42
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)

Permalink | Reply | 0 comments |
headers
Jukka Salmi | 17 Nov 2009 21:38
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)

Permalink | Reply | 0 comments |

Gmane