Ryosuke Moro | 15 Aug 13:51 2015

AMD A8-3870


NetBSD 7.99.20 i386

GENERIC kernel does not boot, so i use modified kernel like this
	#radeon*    at pci? dev ? function ?
	#radeondrmkmsfb* at radeonfbbus?

a bit strange lines in /var/log/Xorg.0.log

[    66.831] (II) VESA: driver for VESA chipsets: vesa
[    66.852] (--) Using wscons driver on /dev/ttyE1 in pcvt compatibility mode (version 3.32)
[    66.852] (--) using VT number 2
[    66.860] (II) Loading /usr/X11R7/lib/modules/drivers/radeon_drv.so
[    66.860] drmOpenDevice: node name is /dev/dri/card0
[    66.902] drmOpenDevice: open result is -1, (Device not configured)
[    66.903] drmOpenDevice: open result is -1, (Device not configured)
[    66.903] drmOpenDevice: Open failed
[    66.903] drmOpenByBusid: Searching for BusID pci:0000:00:01.0
[    66.903] drmOpenDevice: node name is /dev/dri/card0
[    66.903] drmOpenDevice: open result is -1, (Device not configured)
[    66.904] drmOpenDevice: open result is -1, (Device not configured)
[    66.904] drmOpenDevice: Open failed
[    66.904] drmOpenByBusid: drmOpenMinor returns -6
[    66.904] drmOpenDevice: node name is /dev/dri/card1
[    66.904] drmOpenDevice: open result is -1, (Device not configured)
[    66.904] drmOpenDevice: open result is -1, (Device not configured)
[    66.904] drmOpenDevice: Open failed
[    66.904] drmOpenByBusid: drmOpenMinor returns -6
[    66.904] drmOpenDevice: node name is /dev/dri/card2
(Continue reading)

Robert Swindells | 11 Aug 16:09 2015

X11 drivers for SoCs

I have been trying to work out the best way to add some accelerated
X11 support for the AllWinner ARM SoCs but the possible solutions
may be useful for things like the CI20 MIPS SoC too.

The GPUs on them are undocumented but several SoCs also have 2d and
video hardware that is documented.

There is a Linux driver xf86-video-fbturbo that is derived from the
unaccelerated xf86-video-fbdev driver. It adds support for HW cursors,
video and the hooks for the Mali GPU when run on AllWinner ARM SoCs.

The HW cursor code duplicates what we have in wsdisplay(4) in the

I don't know whether we need to think about hooks for the Mali (or
PowerVR) 3D GPUs. If we don't think we will ever use these GPUs then
maybe don't need DRI either.

The options that I can think of are:

      Add NetBSD conditional code to xf86-video-fbturbo.

      Fork xf86-video-wsfb for each SoC and add video and 2d support.

      Add conditional code to xf86-video-wsfb.

Thoughts ?

Robert Swindells
(Continue reading)

Robert Swindells | 13 May 09:51 2015

Alternative intel driver

I have local patches that allow the final version of the intel driver
with support for UMS to be built against the xorg server that is in

The netbook of mine that wouldn't work with KMS seems fine now.

Is it still worthwhile importing it into the tree ?

It could help with PR 49330 I guess.

Robert Swindells

Yorick Hardy | 21 Apr 16:07 2015

libxcb-xkb.so version

libxcb-xkb.so does not have the intended version, the patch below
(relative to src/) is a proposed fix.

Kind regards,

Yorick Hardy

Index: distrib/sets/lists/xbase/shl.mi
--- distrib/sets/lists/xbase/shl.mi
+++ distrib/sets/lists/xbase/shl.mi
 <at>  <at>  -419,12 +419,12  <at>  <at> 
 ./usr/X11R7/lib/libxcb-xfixes.so.0.1		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xinerama.so		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xinerama.so.0		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xinerama.so.0.1		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xkb.so			-unknown-		xorg
-./usr/X11R7/lib/libxcb-xkb.so.0			-unknown-		xorg
-./usr/X11R7/lib/libxcb-xkb.so.0.1		-unknown-		xorg
+./usr/X11R7/lib/libxcb-xkb.so.1			-unknown-		xorg
+./usr/X11R7/lib/libxcb-xkb.so.1.0		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xtest.so			-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xtest.so.0		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xtest.so.0.1		-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xv.so			-unknown-		xorg
 ./usr/X11R7/lib/libxcb-xv.so.0			-unknown-		xorg

Index: external/mit/xorg/lib/libxcb/xkb/Makefile
(Continue reading)

matthew green | 17 Apr 22:48 2015

RFC: remove xsrc/xfree

hi folks.

we've had moderate success in porting all the old X servers to
xorg infrastructure, but there are a handful of stragglers, from

.if \
    ${MACHINE} == "acorn32"     || \
    ${MACHINE} == "alpha"       || \
    ${MACHINE} == "amiga"       || \
    ${MACHINE} == "mac68k"      || \
    ${MACHINE} == "pmax"        || \
    ${MACHINE} == "sun3"
X11FLAVOUR?=    XFree86

this match up with these subdirs in xsrc/xfree/xc/programs/Xserver/hw:


this is the only reason we still have xfree sources around, and
while we've gotten most of the servers ported (mostly thanks to
macallan <at>  and tsutsui <at> ), it's time to move on and stop supporting
this code base (i've had to patch it several times this year for
security issues, and sometimes the backport has been non trivial.)
(Continue reading)

Manuel Bouyer | 6 Apr 20:02 2015

HEAD on intel graphics

I'm happy to report that with the latest HEAD fixes to drm2, I don't
experience any display corruption on the i965GM that I used to see.
This should definitively be pulled up to netbsd-7 !


Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference

Tobias Nygren | 2 Apr 12:52 2015

Intel HD 5500 GPU hang


Not having much luck getting acceleration to work with my Thinkpad
x250 which has Broadwell HD 5500 integrated graphics. Immediately after
startx I get:

drm: GPU HANG: ecode 0:0x0fdffdff, reason: Ring hung, action: reset
drm: GPU crash dump saved to /sys/class/drm/card0/error

I tried to create the directory but it did not save anything. Anyone
know how to debug such problems? After a minute or so of rendering
corruption and hangs, Xorg.log finally says:

[    96.773] (EE) intel(0): Failed to submit rendering commands,
disabling acceleration.

... after which it seems to run OK.

I've already tried to update to the latest everything[1] which has
proven pretty stable on my desktop setup with Radeon HD 5450 graphics.


[1] NetBSD-current, xorg-server-1.17.1 and MesaLib-10.5.1 from wip,
    xf86-video-intel from git, libdrm locally updated to 2.4.60 since
    it mentioned several intel fixes.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
(Continue reading)

rjs | 23 Mar 17:43 2015

Alternative X11 drivers

We have two versions of radeon driver in the tree, which one gets built is
selected by a make variable.

I have been working on getting an older intel driver working too, I have been
building it as well as the existing one.

I think I prefer to have both built and rename the driver files so that X11
finds the one I want but it is probably best to follow the same pattern for
radeon and intel.

What do people think ?

Robert Swindells

Phil Rulon | 6 Mar 20:12 2015

client side hackers note.

After struggling for some time trying to get a 20 year old
program to build under (7_BETA) bsd.x11.mk, an unrelated
browse through <sys/cdefs.h> revealed this handy item:

 * The following macro is used to remove const cast-away warnings
 * from gcc -Wcast-qual; it should be used with caution because it
 * can hide valid errors; in particular most valid uses are in
 * situations where the API requires it, not to cast away string
 * constants. We don't use *intptr_t on purpose here and we are
 * explicit about unsigned long so that we don't have additional
 * dependencies.
#define __UNCONST(a)    ((void *)(unsigned long)(const void *)(a))

Quite useful when passing input to vaguely declared Xlib routines
expecting, say, a char* while using -Wwrite-strings and -Wcast-qual.

A further advantage to judicious use of this is, that it will serve
to identify Xlib routines that might be more carefully declared, for
the upstream channel.

It is perceivable that this is well known to some or many on this
list, but for those, like me, who were unaware of it, a handy, if
sub-optimal, fix.

Like it says, use with caution.


matthew green | 1 Mar 09:01 2015

README - x86 switched to KMS-only ati drivers by default

hi folks.

i've switched the x86 ports to installing xf86-video-ati 7.x radeon
driver by default, so that we get support for the latest cards and
better support for older cards.  this means that the old drm code
will no longer work with the radeon xf86 driver.

if you're still using the old radeondrm code, you'll be able to 
keep the old driver installing by setting MKX11RADEONKMS=no in your
mk.conf/environment before building.  or simply make the installed
/usr/X11R7/lib/modules/drivers/radeon_drv.so point to the old .so.6

please send-pr (or reply to this thread) if you notice any new



Taylor R Campbell | 28 Feb 06:51 2015

HEADS UP: graphics driver fixes

tl;dr: If DRM/KMS has been flaky for you, please try again in HEAD!

I recently found a bit of spare time to look for bugs I'd left in
DRM/KMS which have left a lot of systems kinda-sorta working but not

In so doing, I found several classes of bugs related to timeouts --
about two dozen different bugs altogether, in different timed waits,
including detecting displays, waiting for rendering commands to
complete, and waiting for vertical blanks.  This affects all DRM
drivers (at the moment, just Intel and Radeon).

I've reviewed all these timed waits, and I don't see any more of these
bugs.  Obviously this code could use more eyeballs!  (Grep for
`DRM_.*WAIT.*_UNTIL' if you'd like to lend yours.)  But if you've been
having trouble with blank screens or flaky rendering or frequent hangs
-- I can't promise anything, but please try again with a kernel from
HEAD and let me know how it goes.

P.S.  Nouveau now compiles, although it doesn't link yet.  Needs a bit
more work to get it to a state that can be tested, but most of the
tedious work is done.  Let me know if you'd like to take a stab at it
and I'd be happy to set you in the right direction.

P.P.S.  If you've sent me mail about graphics issues and I haven't
replied, I'm sorry -- I have been too busy to deal with this properly
in the past few months.  If these changes don't fix your issue, please
file a PR so it'll be less likely to be forgotten.