This is limited to some users of specific Intel video chipsets, but: if you get odd screen artifacts in X, the ‘vesa’ driver may work just fine for you. Or turn acceleration off. Or set ‘drm.i915.enable_execlists=0’ according to zrj on #dragonflybsd.
(Updated to reflect all the answers in the thread and elsewhere.)
There are USB devices out there that are sort of like a mouse, as in they work as a pointing device, but they don’t show up as a mouse device. For example, the PowerMate USB Multimedia Controller. It’s possible to pipe the events from this or similar ‘weird’ devices to sysmouse, and use it the way you’d expect, with this fix from user tautology.
If you have iwm(4) network hardware, that driver now supports some more chipsets, plus it’s had some other updates, courtesy of Imre Vadasz.
(I think I spelled Imre’s name right for once!)
Matthew Dillon has been testing on more NVMe hardware, or at least what is supposed to be NVMe hardware, and he has a writeup of the results that may be useful for anyone planning a shopping trip soon.
Matthew Dillon has written a new, from scratch, driver for NMVe in DragonFly. If you haven’t encountered it yet, that’s SSD access over PCIe, which gives better throughput than ATA. He’s posted a summary of his work, and it’s possible to load it now as a module. It supports MSI-X, and there’s test results from using dd on supported NVMe hardware.
Really, last minute – assembled from random tabs I’ve been saving, late Friday.
If you are running DragonFly in a virtual environment, there’s been some improvements to virtio(4). Update and try if you’ve had problems in the past.
If you have a ral(4) wireless card that didn’t function as expected, it may suddenly work for you now on DragonFly 4.5 due to the large wifi update. The ral(4) driver covers a lot of hardware, so check the man page for all the commercial names.
Matthew Dillon and Adrian Chadd have updated the wifi setup in DragonFly, incorporating Adrian’s FreeBSD changes (and merging back some of Matt’s from DragonFly). This affects the ath, rum, iwm, iwn, run, bwn, urtwn, wi, ral, iwi, ndis, and wpi drivers. The ‘an’ driver has been removed, too. I’m not going to even try to link to all the commits.
If you’re on DragonFly master and are using one of these devices, now is the time to update and try. Note that this removes the separate network interface that’s specific to the device and creates only a wlanX device.
Update: Matt reminded me that at least half the work came from Imre Vadasz; I missed it because I was only looking at the commit email names – mea culpa.
Read this email thread for how to mount devices (e.g. USB drives) in DragonFly when you aren’t root.
If you get “libGL error: failed to open drm device: Permission denied” when using direct rendering, make sure to add your user id to the ‘video’ group.
The drm/i915 driver has been updated by Francois Tigeot to match what’s in Linux kernel 4.3. His commit post has the general detail; you will especially want this if on DragonFly-current and running on Skylake architecture.
If you’ve ever wondered how having multiple swap devices can work, here’s your DragonFly-specific answer.
If you remember this Baytrail problem, Daniel Bilik has gone and found a fix, as this appears to be a cross-platform bug, and he has patches for DragonFly. If it’s affecting you, you don’t have to wait for the patches to be added in; he’s made them available directly.
Update: it’s committed to DragonFly now.
Do you have a Cherry Trail SoC? For example, a HP x2 210? Imre Vadasz’s recent commit may be useful for you, if you are running DragonFly on this detachable … thing?
Tim Darby is looking for motherboard recommendations. Specifically, mini-ITX with 4 SATA ports and at least one decent network link. Who’s got hardware to recommend? There’s already one set of suggestions.
If you have a Radeon video card in your DragonFly system, and are running bleeding-edge, there’s an update for you. This is a partial sync with Radeon code for Linux 3.18, with no additional notes in the commit but you can always check elsewhere.
If you somehow have a device with multiple SD/MMC card slots, you can now access all of them under DragonFly. (Apparently done to make a tablet run DragonFly better, going by IRC conversation)
John Marino rearranged how GCC5 handles CPUTYPE settings. If you are specifically setting the target CPU when compiling, his commit will give you an exact list of what to target.
Note that I am not saying another architecture – this is all x86_64. I also don’t recommend doing this unless you have a specific use for it – compiler overoptimizations often create more problems than they fix.
Daniel Bilik has found there’s an issue with i915 acceleration, Baytrail CPUs, and some AUTODEEP low-power states. This will only affect you if you are using that specific hardware combo and setting certain low power modes. Interestingly, it affects other platforms, too, as it appears to be a symptom of how the video is addressed, not a DragonFly-specific bug.