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.

(Continue reading)

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.


Thomas Klausner | 23 Feb 12:33 2015

NetBSD-local xf86-video-tdfx diff

Hi Michael!

I've reduced our local changes to xf86-video-tdfx to the attached diff
(vs. upstream git version).

If I read the code correctly, there are the following effective
changes (committed with the message that this makes the driver work on
macppc with one card):

* If there is only one card, the following code is not executed:

   (with the MMIOAddr with the lowest 256 bytes set to whatever)


   (with the LinearAddr with the lowest 256 bytes set to whatever)

        PCI_WRITE_LONG(pTDFX->LinearAddr[i], CFG_MEM1BASE, i);

        PCI_WRITE_LONG(cfgbits, CFG_PCI_DECODE, i);
        PCI_WRITE_LONG(initbits, CFG_INIT_ENABLE, i);

* There's a complete reversal of an ifdef which I don't understand:

+  /* access VGA registers through the IO BAR, not legacy decoding */
   hwp->PIOOffset = pTDFX->PIOBase[0] - 0x300;

I don't think I can feed this back upstream with what I know. Can you
please explain why the WRITE_LONG are bad, and why the ifdef needed to
become an ifndef?

diff --git a/src/tdfx_driver.c b/src/tdfx_driver.c
index 03fa165..b15ff9c 100644
--- a/src/tdfx_driver.c
+++ b/src/tdfx_driver.c
 <at>  <at>  -661,7 +661,20  <at>  <at>  TDFXInitChips(ScrnInfoPtr pScrn)
     xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, 3,
 		   "TDFXInitChips: cfgbits = 0x%08lx\n", cfgbits);

-    for (i = 0; i < pTDFX->numChips; i++) {
+    if (pTDFX->numChips == 1) {
+      /*
+       * Do not fudge BARs with only one chip present.
+       */
+      pTDFX->MMIOAddr[0] = mem0base & 0xffffff00;
+      pTDFX->LinearAddr[0] = mem1base & 0xffffff00;
+      xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, 3,
+		     "TDFXInitChips: MMIOAddr[%d] = 0x%08lx\n",
+		     0, pTDFX->MMIOAddr[0]);
+      xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, 3,
+		     "TDFXInitChips: LinearAddr[%d] = 0x%08lx\n",
+		     0, pTDFX->LinearAddr[0]);
+    } else {
+      for (i = 0; i < pTDFX->numChips; i++) {
 	PCI_WRITE_LONG(initbits | BIT(10), CFG_INIT_ENABLE, i);

 #if 0
 <at>  <at>  -692,6 +705,7  <at>  <at>  TDFXInitChips(ScrnInfoPtr pScrn)

+      }

 <at>  <at>  -2230,7 +2244,8  <at>  <at>  TDFXScreenInit(SCREEN_INIT_ARGS_DECL) {

   if (!pTDFX->usePIO) TDFXSetMMIOAccess(pTDFX);

+  /* access VGA registers through the IO BAR, not legacy decoding */
   hwp->PIOOffset = pTDFX->PIOBase[0] - 0x300;
Phillip Rulon | 22 Feb 21:05 2015

xconsole/getty 7_BETA

While running xconsole from an xdm launched session, a profusion of getty restarts is showing up in the xconsole window.  Each time it happens /var/log/wtmpx gets updated.  If xconsole is shut off, it goes away.  Is it possible that getty is viewing log messages as failed logins under these circumstances?

# last -f /var/log/wtmpx

produces what's expected, there is only one user (root) logged on. The login time is correct.  I have not tried doing this as some other user.  Occassionally a "getty respawning too fast" message shows up.  There's only one user logged in on this box and /var/log/wtmpx is now > 2 Meg after 24 hours of no one else logging in.

7.0_BETA (GENERIC.201502171530Z) i386

Apologies if this is known or expected behavior.


Phillip Rulon | 19 Feb 03:57 2015

replace twm with cwm?

I mentioned in a previous thread the I was having a look at cwm.  So far I haven't any feedback.  It would be a significant step from what new users might expect but it has enormous potential.  I built it out of pkgsrc but that code is pretty far back from what's happening these days.  The folks over at OpenBSD have done a hell of a lot of work on it.

I'm not really up on the politics of cross-porting code from those guys but if it makes sense to run cwm, it makes sense to cross-port it.

Personally I favor it, but I'll work in any wm that makes sense to the project.  There are issues above my pay grade on this considering the implications of adopting a look and feel that was developed by another project.  It does imply increased consistency across the BSD community though.

Then again, I don't even know if the folks on this list think cwm is a good idea at all.

Like I said above, I'll hack any setup that works for the project, but this is kind of a design/philosophy choice where a little guidance might be useful.


Phillip Rulon | 16 Feb 21:07 2015

Beyond twm

I was browsing the projects list and ran across the page at:

The posting was about 11 months ago.  I agree that the default twm environment is dated.  The suggestion of importing golem into base is a reasonable one.  I've had a look at the golem source and there is certainly lots of hair on it.  The default install is sub-optimal.  But it is BSD code so would fit comfortably into base.  By the time it was decruftified it would almost be a fork.  The page indicates the the code might be made available to NetBSD as a donation.  It could be a reasonable starting point for a better default X landing zone.

The questions I have are:  Is this still relevant?   Is anyone looking at it by now?

Phil Rulon
prulon <at>
pjr <at>

Thomas Klausner | 1 Feb 11:00 2015

Xorg built with clang dumps core, with gcc not


I'm seeing strange behaviour. I've updated to 7.99.4 from yesterday
and tried a build with clang as default compiler, i.e. "-V MKLLVM=yes
-V HAVE_LLVM=yes -V MKGCC=no" in my command line.

When I installed that kernel and userland, starting X just gave me a
black screen and I couldn't switch back to console; i.e. X probably
just died.

Xorg.0.log contains:
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jan 31 21:26:07 2015
(==) Using config file: "/etc/X11/xorg.conf"
(II) [KMS] Kernel modesetting enabled.
(EE) RADEON(0): Cannot position output DVI-0 relative to unknown output Left Monitor
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:            Couldn't lookup keysym
>                   Symbol interpretation ignored
> Error:            Couldn't lookup keysym
>                   Symbol interpretation ignored
Errors from xkbcomp are not fatal to the X server
Can't open display :0

Then I tried building the same sources with gcc as compiler, and X
works. Xorg.0.log:
(==) Log file: "/var/log/Xorg.1.log", Time: Sat Jan 31 21:26:59 2015
(==) Using config file: "/etc/X11/xorg.conf"
(II) [KMS] Kernel modesetting enabled.
(EE) RADEON(0): Cannot position output DVI-0 relative to unknown output Left Monitor
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:            Couldn't lookup keysym
>                   Symbol interpretation ignored
> Error:            Couldn't lookup keysym
>                   Symbol interpretation ignored
Errors from xkbcomp are not fatal to the X server
xrandr: cannot find mode 1920x1200
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  118 (X_SetModifierMapping)
  Value in failed request:  0x17
  Serial number of failed request:  15
  Current serial number in output stream:  15
2015-01-31 21:27:00 INFO  /notion/../ioncore.c:609: ioncore_startup: Starting Notion

This even works with the kernel built with clang (i.e. gcc /usr/X11R7
on top of clang /netbsd).

When I start /usr/X11R7/bin/Xorg in gdb (as root), the clang-built X
works: I can start xterms and a window manager.

Then I noticed that starting X (using startx) as my user gives me an
Xorg.core file (I thought it didn't do that for setuid root files?!).
Here's the backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  radeon_dri2_unref_buffer (buffer=0x1) at /archive/foreign/xsrc/external/mit/xf86-video-ati/dist/src/radeon_dri2.c:584
584             struct dri2_buffer_priv *private = buffer->driverPrivate;
(gdb) bt
#0  radeon_dri2_unref_buffer (buffer=0x1) at /archive/foreign/xsrc/external/mit/xf86-video-ati/dist/src/radeon_dri2.c:584
#1  radeon_dri2_client_state_changed (ClientStateCallback=0x8591a0 <ClientStateCallback>,
data=0x0, calldata=<optimized out>)
    at /archive/foreign/xsrc/external/mit/xf86-video-ati/dist/src/radeon_dri2.c:610
#2  0x000000000046dbdc in _CallCallbacks (pcbl=0x8591a0 <ClientStateCallback>, call_data=0x7f7fffffd3b0)
    at /archive/foreign/xsrc/external/mit/xorg-server/dist/dix/dixutils.c:742
#3  0x0000000000453ea1 in CallCallbacks (pcbl=<optimized out>, call_data=0x0) at /archive/build/amd64.clang.20150131/usr/X11R7/include/xorg/callback.h:86
#4  CloseDownClient (client=0x7f7ff5fcda10) at /archive/foreign/xsrc/external/mit/xorg-server/dist/dix/dispatch.c:3461
#5  0x0000000000453cb7 in Dispatch () at /archive/foreign/xsrc/external/mit/xorg-server/dist/dix/dispatch.c:416
#6  0x000000000042e417 in main (argc=1, argv=0x7f7fffffd4c8, envp=<optimized out>) at /archive/foreign/xsrc/external/mit/xorg-server/dist/dix/main.c:287

I'm not sure what could be the cause of this. My latest idea is that
the failed request in the gcc log somehow kills the clang X, perhaps
because some data structures are packed differently (just guessing).

Does anyone have an idea?

Anibal Limón | 27 Jan 17:14 2015

xf86-video-ati status/new cards


I'm using NetBSD-current (7.99.4) with Radeon 8970 HD Graphics (ARUBA) and didn't work by default.

Then i made a patch that adds this card to src/pcidb/ati_pciids.csv, renegerate headers with pl script, build and works.

The support is available in the kernel radeondrmkms and in the libdrm, the unique lack part is xf86-video-ati but upstream have support for it.

- It is target to make upgrade of xf86-video-ati?
- Someone is working on it?

Kind regards,

Leonardo Taccari | 26 Jan 04:39 2015

Re: CVS commit: pkgsrc/fonts/harfbuzz

Hello Thomas and matthew,

Leonardo Taccari writes:
> Attached in this email there is a patch that fixes the harfbuzz-0.9.38
> problem. It's a quick work-around and needs to be reviewed.
After trying to analyze a pkgsrc/fonts/harfbuzz problem it seems that
PKGCONFIG_VERSION.freetype2 in src/external/mit/xorg/lib/freetype was
not bumped during the updates (I cc-ed mrg <at>  and tech-x11 <at>  for this
xsrc/external/mit/freetype/dist/docs/VERSION.DLL seems also to confirm

 release     libtool     so
   2.5.3     17.2.11    6.11.2
   2.3.9      9.20.3    6.3.20

...while according to pkg-config(1) we have:

 $ pkg-config --modversion freetype2

Indeed it seems that PKG_CONFIG_VERSION.freetype2 was added in -r1.4 of
Makefile (freetype2-2.3.9) and then it was not bumped.

After applying the patches the work-around for harfbuzz-0.9.38 that I
have posted in my previous email will be no more needed.

I will attach a possible patch to fix this issue. Please review it
because it is the first time that I am touching a xsrc Makefile (and I
have not tested it).

Thank you for your attention,
Attachment (patch-freetype-Makefile): text/x-diff, 481 bytes