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
Picon version 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/		-unknown-		xorg
 ./usr/X11R7/lib/		-unknown-		xorg
 ./usr/X11R7/lib/		-unknown-		xorg
 ./usr/X11R7/lib/		-unknown-		xorg
 ./usr/X11R7/lib/			-unknown-		xorg
-./usr/X11R7/lib/			-unknown-		xorg
-./usr/X11R7/lib/		-unknown-		xorg
+./usr/X11R7/lib/			-unknown-		xorg
+./usr/X11R7/lib/		-unknown-		xorg
 ./usr/X11R7/lib/			-unknown-		xorg
 ./usr/X11R7/lib/		-unknown-		xorg
 ./usr/X11R7/lib/		-unknown-		xorg
 ./usr/X11R7/lib/			-unknown-		xorg
 ./usr/X11R7/lib/			-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>>
     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), 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/ 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.

Wolfgang Solfrank | 25 Feb 16:11 2015

Re: Radeondrm on R7 250 w 3840x2160


> So now things work more or less as expected, except that I have
> to boot several times to get to see something on the screen.

I finally found some round tuits to look into this.

The problem is that the kernel panics after starting to initialize
the radeon drmkms machinery, but before it finishes.

The radeon configuration attach code is delayed until after root is
mounted in order to be able to load the firmware.  Right after it
starts, some other thread tries to open the console, however,
radeondrmkms didn't yet initialize the that, and so it panics
with "cnopen: no console device".  As a result, the initialization
of radeondrmkms is also aborted, and thus I don't see anything.


Wolfgang <at>				Wolfgang Solfrank

Phillip Rulon | 23 Feb 18:18 2015

xconsole/getty 7_BETA

After a few private volleys with knowledgeable people, the suggestion was made that this be brought back to the list.

To recap the behavior:

If xdm is specified in sysinst, getty and xconsole argue over who's got the console.  /var/log/wtmpx fills up unusually fast and xconsole cycles getty login output about every 30 seconds.  If xconsole is shut off the behavior goes away.  If console is shutoff in /etc/ttys, the behavior goes away.

A possible fix is to have custom start/stop routines in /etc/rc.d/xdm which mod the ttys file and HUP init.  Hopefully a more elegant solution can be found.

# uname -a
NetBSD 7.0_BETA NetBSD 7.0_BETA (GENERIC.201502171530Z) i386

To reproduce the behavior, a stock 7.0_BETA install can be done on a naked machine, specifying xdm to sysinst.  After the first reboot, monitor xconsole and the size growth of /var/log/wtmpx.

The test machine is i386, though it's doubtful that the behavior is isolated to this port.