Re: NetBSD as an NTP stratum 1 server
jo...@sdf.org writes:
>>> Greg Troxel writes:
>>>
Brad Spencer writes:
(The advice about "use gpio" is good - I am just trying to clarify USB
PPS.)
>>>
>>> It has worked very well for me, assuming that the GPS module is stable.
>>> I had one that would have a tendency to crash in its firmware after
>>> being up for a while and totally lose its mind.
>>>
>>
>> Thanks for the detailed information and discussion.
>>
>> I built a kernel for my Rock64 on its bigger sibling RockPro64 (has a PCIe
>> SSD card) -- sorry, okay, that was me just saying how much I enjoy these 2
>> devices! Anyway...I ran into a problem initializing gpiopps. Here is the
>> Rock64 output when initializing with gpio.conf:
>> [1.04] gpiopps0 at gpio1 pins 28
>> [1.04] gpiopps0: autoconfiguration error: positive edge interrupt
>> not supported for ASSERT
>> I also booted single user and it fails using gpioctl. Taking a peek at
>> src/sys/dev/gpio/gpiopps.c this would be in the second if-block (1 pin) in
>> gpiopps_attach:
>> if (!gpio_intr_str(sc->sc_gpio, >sc_map, 0,
>>sc->sc_intrs[0].sc_irqmode,
>>sc->sc_intrs[0].sc_intrstr,
>>sizeof(sc->sc_intrs[0].sc_intrstr))) {
>> aprint_error_dev(self,
>> "failed to decode interrupt\n");
>> gpio_pin_unmap(sc->sc_gpio, >sc_map);
>> return;
>> Here's what I added to evbarm/conf/GENERIC64:
>> gpiopps* at gpio1 offset 28 mask 0x1 flag 0x2
>> This is for physical pin 7 which per pine64 wiki is GPIO1_D4. So gpio1 and
>> D=3, so 3*8 + 4 = port 28.
>>
>> I tried also modifying the RockPro64 kernel -- similar issue.
>>
>> Any idea what am I doing wrong?
>>
>> Thanks - Joel
>>
>>
> And sorry, wrong code block from gpiopps.c:
> } else {
> aprint_error_dev(sc->sc_dev,
> "%s edge interrupt not supported for ASSERT\n",
> assert_edge == GPIO_INTR_POS_EDGE ? "positive"
> : "negative");
> gpio_pin_unmap(sc->sc_gpio, >sc_map);
> return;
> }
A followup to myself
Looking at rk_gpio.c it appears that interrupts are not supported for
the Rock64 systems in the NetBSD driver for the Rockchip. However, the
technical reference manual for the RK3328 and RK3399 suggest that those
two variants support interrupts on the GPIO pins, so it might just be a
matter of software. The rest of the variants might also have support I
just didn't look. I don't have this particular SOC system, so will be
of little help, but a quick read of the TRM suggests that it isn't
largely different from how the Broadcom (RPI family) GPIO interrupts
work and it wasn't that hard to add GPIO interrupt support for Broadcom
when I did that years ago.
So for right now, it looks like you may be out of luck for ntpd PPS use
on a Rock64 system (except for the USB DCD support which would work if
the GPS chip supports it).
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: recent strange sudo behavior, probably due to /dev/pts
Greg Troxel writes: > After a lot of investigating including writing a quick read/printf > program to examine the sudo timestamp files, the problem appears to be > that the timestamp records are "TS_PPID" rather than "TS_TTY". The > parent is something deep in make, and thus different every time. So > this is not really a pkgsrc issue. Followup for the archives. There are two problems that combine for hard-to-debug bad behavior. 1) devname(3) devname(3) converts a device major/minor to a pathname. sudo uses this. However, it uses /var/run/dev.cdb, which is created by dev_mkdb(8) which runs at boot. So if you boot your system with /dev/ttyp*, mount ptyfs, rm /dev/ttyp*, and log out and back in, you will still get e.g. /dev/ttyp5 from devname. (I saw this in the sudo logs.) 2) sudo bugs sudo's default is 'tty'. It gets the major/minor. But it doesn't just store that in the timestamp file. It calls devname, and if it can't stat the result, *silently*, even with respeect to debugging statements, switches to ppid mode. If it can stat, it stores the dev_t in the file. See plugins/sudoers/timestamp.c, line 415, where it checks that stat succeeds on the path. The bad bug is that failure to stat a path that should be valid should be fatal, not a silent flip to ppid. The lesser bug is that if the thing that matters is the dev_t, it should just use that. Once realizing, re-running dev_mkdb caused devname to return /dev/pts/5 instead, and things work as I would expect.
Re: NetBSD as an NTP stratum 1 server
jo...@sdf.org writes:
>>> Greg Troxel writes:
>>>
Brad Spencer writes:
(The advice about "use gpio" is good - I am just trying to clarify USB
PPS.)
>>>
>>> It has worked very well for me, assuming that the GPS module is stable.
>>> I had one that would have a tendency to crash in its firmware after
>>> being up for a while and totally lose its mind.
>>>
>>
>> Thanks for the detailed information and discussion.
>>
>> I built a kernel for my Rock64 on its bigger sibling RockPro64 (has a PCIe
>> SSD card) -- sorry, okay, that was me just saying how much I enjoy these 2
>> devices! Anyway...I ran into a problem initializing gpiopps. Here is the
>> Rock64 output when initializing with gpio.conf:
>> [1.04] gpiopps0 at gpio1 pins 28
>> [1.04] gpiopps0: autoconfiguration error: positive edge interrupt
>> not supported for ASSERT
>> I also booted single user and it fails using gpioctl. Taking a peek at
>> src/sys/dev/gpio/gpiopps.c this would be in the second if-block (1 pin) in
>> gpiopps_attach:
>> if (!gpio_intr_str(sc->sc_gpio, >sc_map, 0,
>>sc->sc_intrs[0].sc_irqmode,
>>sc->sc_intrs[0].sc_intrstr,
>>sizeof(sc->sc_intrs[0].sc_intrstr))) {
>> aprint_error_dev(self,
>> "failed to decode interrupt\n");
>> gpio_pin_unmap(sc->sc_gpio, >sc_map);
>> return;
>> Here's what I added to evbarm/conf/GENERIC64:
>> gpiopps* at gpio1 offset 28 mask 0x1 flag 0x2
>> This is for physical pin 7 which per pine64 wiki is GPIO1_D4. So gpio1 and
>> D=3, so 3*8 + 4 = port 28.
>>
>> I tried also modifying the RockPro64 kernel -- similar issue.
>>
>> Any idea what am I doing wrong?
>>
>> Thanks - Joel
>>
>>
> And sorry, wrong code block from gpiopps.c:
> } else {
> aprint_error_dev(sc->sc_dev,
> "%s edge interrupt not supported for ASSERT\n",
> assert_edge == GPIO_INTR_POS_EDGE ? "positive"
> : "negative");
> gpio_pin_unmap(sc->sc_gpio, >sc_map);
> return;
> }
I failed to mention this before, and I don't think that the gpiopps(4)
man page mentions this, but you need a device that supports GPIO
interrupts to use gpiopps(4). Not all of the SOC systems support that.
The message you are getting very much implies that interrupts are not
supported in the configuration you are trying to use (which wasn't
exactly metioned).
There are several possible situations... for example, the RPI family
supports GPIO interrupts on the positive and negative edge of the pulse
and at the same time (gpiosim(4) does too now, but that is a GPIO
simulator). It may be that your device only supports it on one edge or
the other or not at all. The ntpd PPS driver, I seem to remember,
supports using just one edge and I think I remember that it could be
either one (or it use both edges). You can configure gpiopps(4) to do
any of those cases. You can also try using gpioirq(4) and see if
interrupts work at all, if you can't find documentation anywhere for
your device. If you can get interrupts on one edge working I think you
win with ntpd, otherwise that device can't be used.
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: iscsid - lfs and ipv6 issues
lis...@nebelschwaden.de (Ede Wolf) writes: >I am having two issues with iscsid/iscsictl. First, it seems, I cannot >mount an lfs formatted iscsi lun, no matter wether this drive is >gpt/wedge or plain disklabelled: ># mount -t lfs /dev/dk0 /import/ >mount_lfs: /dev/dk0 on /import: Operation not supported by device This works here (as far as lfs works), but the error message is rare. One possibility is that the SCSI driver reports an offline unit. Can you tell what the iSCSI server is ? >scsictl: add_send_target: Invalid option at or near '-a': Bad address >format: Extra character(s) ':' The address parser looks broken. For some reason the first character is skipped when it tries to identify IPv6, I was successful with iscsictl add_send_target -a 'x[ipv6-address]' Greetings,
Re: NetBSD as an NTP stratum 1 server
>> Greg Troxel writes:
>>
>>> Brad Spencer writes:
>>>
>>> (The advice about "use gpio" is good - I am just trying to clarify USB
>>> PPS.)
>>
>> It has worked very well for me, assuming that the GPS module is stable.
>> I had one that would have a tendency to crash in its firmware after
>> being up for a while and totally lose its mind.
>>
>
> Thanks for the detailed information and discussion.
>
> I built a kernel for my Rock64 on its bigger sibling RockPro64 (has a PCIe
> SSD card) -- sorry, okay, that was me just saying how much I enjoy these 2
> devices! Anyway...I ran into a problem initializing gpiopps. Here is the
> Rock64 output when initializing with gpio.conf:
> [1.04] gpiopps0 at gpio1 pins 28
> [1.04] gpiopps0: autoconfiguration error: positive edge interrupt
> not supported for ASSERT
> I also booted single user and it fails using gpioctl. Taking a peek at
> src/sys/dev/gpio/gpiopps.c this would be in the second if-block (1 pin) in
> gpiopps_attach:
> if (!gpio_intr_str(sc->sc_gpio, >sc_map, 0,
>sc->sc_intrs[0].sc_irqmode,
>sc->sc_intrs[0].sc_intrstr,
>sizeof(sc->sc_intrs[0].sc_intrstr))) {
> aprint_error_dev(self,
> "failed to decode interrupt\n");
> gpio_pin_unmap(sc->sc_gpio, >sc_map);
> return;
> Here's what I added to evbarm/conf/GENERIC64:
> gpiopps* at gpio1 offset 28 mask 0x1 flag 0x2
> This is for physical pin 7 which per pine64 wiki is GPIO1_D4. So gpio1 and
> D=3, so 3*8 + 4 = port 28.
>
> I tried also modifying the RockPro64 kernel -- similar issue.
>
> Any idea what am I doing wrong?
>
> Thanks - Joel
>
>
And sorry, wrong code block from gpiopps.c:
} else {
aprint_error_dev(sc->sc_dev,
"%s edge interrupt not supported for ASSERT\n",
assert_edge == GPIO_INTR_POS_EDGE ? "positive"
: "negative");
gpio_pin_unmap(sc->sc_gpio, >sc_map);
return;
}
Re: X on 10.0 RC1 is unusable on my laptop
On Fri, Nov 17, 2023 at 08:36:13PM +, Mike Pumford wrote: > > > Ooh. Haven't come across that before. I also get exactly the same ring > heartbeat issue on my system and looking at the latest linux DRM code the > gen7/gen6 workround code is pretty tiny and trivial to backport. > > I've just popped it into my local tree and I'm giving it a try :) > Very interested in the results of this. I haven't had decent X since I updated. Vesa works but the resolution is pathetic and suspend/resume does not work. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: NetBSD as an NTP stratum 1 server
> Greg Troxel writes:
>
>> Brad Spencer writes:
>>
>> (The advice about "use gpio" is good - I am just trying to clarify USB
>> PPS.)
>
> It has worked very well for me, assuming that the GPS module is stable.
> I had one that would have a tendency to crash in its firmware after
> being up for a while and totally lose its mind.
>
Thanks for the detailed information and discussion.
I built a kernel for my Rock64 on its bigger sibling RockPro64 (has a PCIe
SSD card) -- sorry, okay, that was me just saying how much I enjoy these 2
devices! Anyway...I ran into a problem initializing gpiopps. Here is the
Rock64 output when initializing with gpio.conf:
[1.04] gpiopps0 at gpio1 pins 28
[1.04] gpiopps0: autoconfiguration error: positive edge interrupt
not supported for ASSERT
I also booted single user and it fails using gpioctl. Taking a peek at
src/sys/dev/gpio/gpiopps.c this would be in the second if-block (1 pin) in
gpiopps_attach:
if (!gpio_intr_str(sc->sc_gpio, >sc_map, 0,
sc->sc_intrs[0].sc_irqmode,
sc->sc_intrs[0].sc_intrstr,
sizeof(sc->sc_intrs[0].sc_intrstr))) {
aprint_error_dev(self,
"failed to decode interrupt\n");
gpio_pin_unmap(sc->sc_gpio, >sc_map);
return;
Here's what I added to evbarm/conf/GENERIC64:
gpiopps* at gpio1 offset 28 mask 0x1 flag 0x2
This is for physical pin 7 which per pine64 wiki is GPIO1_D4. So gpio1 and
D=3, so 3*8 + 4 = port 28.
I tried also modifying the RockPro64 kernel -- similar issue.
Any idea what am I doing wrong?
Thanks - Joel
Re: X on 10.0 RC1 is unusable on my laptop
On 14/11/2023 21:22, Brett Lymn wrote: On Tue, Nov 14, 2023 at 08:13:22AM +0100, tlaro...@kergis.com wrote: Just a note that i915drmkms won't apply workarounds to any generation below gen 8, it will probe and attach early versions but it is a bit hit and miss whether it will work or not due to hitting hardware errors. The drm driver appears to be missing some gen 7 devices - like the one in my laptop so you may get a probe failure with that. Ooh. Haven't come across that before. I also get exactly the same ring heartbeat issue on my system and looking at the latest linux DRM code the gen7/gen6 workround code is pretty tiny and trivial to backport. I've just popped it into my local tree and I'm giving it a try :) Here's hoping. Mike
iscsid - lfs and ipv6 issues
Hello, I am having two issues with iscsid/iscsictl. First, it seems, I cannot mount an lfs formatted iscsi lun, no matter wether this drive is gpt/wedge or plain disklabelled: # mount -t lfs /dev/dk0 /import/ mount_lfs: /dev/dk0 on /import: Operation not supported by device Secondly, I am unable to determine the syntax to correctly specfiy an ipv6 address to iscsictl. I've tried the plain address, in square brackets, in double quotes, always getting an error: scsictl: add_send_target: Invalid option at or near '-a': Bad address format: Extra character(s) ':' That is on 10 RC1, but I have never tried this before with earlier versions. Am I missing something or are there any knows issues I should be aware of? Thanks for any insight Ede
Re: recent strange sudo behavior, probably due to /dev/pts
tlaro...@kergis.com writes: > FWIW: In the "tty" entry there is: "If no terminal is present, the behavior > is the same ass ppid." Could it be that the tmux instances are not > recognized as terminal / tty anymore ? > > In doc/CHANGES: > > tmux(1): Import version 3.3a [wiz 20230628] Interesting and a good point. I just ran sudo in an xterm without tmux and the entry in the cache file is still type 3. But great to take tmux out of the picture; I should have tried that before posting.
Re: disklabel: delete a partition?
Am 16.11.23 um 00:19 schrieb John D. Baker:
When using 'disklabel' interactively ('disklabel -i ...'), assigning a
partition a size of zero (0) deletes the partition.
Thanks very much indeed. Took a while for me to being able to test this,
as the box was building packages, but it works as well.
Re: recent strange sudo behavior, probably due to /dev/pts
On Fri, Nov 17, 2023 at 10:50:19AM -0500, Greg Troxel wrote: > My system is netbsd-10. It was installed around 2003 and has been > updated since then, both to each NetBSD stable branch, and to new disks > usually via dump/restore and sometimes rsync. Other than the problem I > am describing in this message, occasional hangs that I blame on ZFS, and > X display glitches, it is working well. > > I have logged in to ttyE0, and ran "xinit .xsession" which starts xfce4 > and I am in an xterm with tmux. > > I had recently noticed that my system did not have /dev/pts, so I grabbed > the line from /etc/fstab on a more recenntly-installed system. I then > removed the /dev/ttyp* type entries. This messed up tmux but logging > out and starting fresh was ok, and this was not surprising. Now the > system is apparently ok execpt for sudo/pkgsrc. > > I have for a long time had in mk.conf: > > SU_CMD=sudo /bin/sh -c > > and "make replace" has invoked sudo, with sudo respecting the > don't-ask-for-password timer as documented. Recently this stopped > working. > > After a lot of investigating including writing a quick read/printf > program to examine the sudo timestamp files, the problem appears to be > that the timestamp records are "TS_PPID" rather than "TS_TTY". The > parent is something deep in make, and thus different every time. So > this is not really a pkgsrc issue. > > I have added: > Defaults timestamp_type=tty > > > Has anyone else seen sudo refusing to use tty as a timestamp type? > > > sudoers(5) excerpt: > > timestamp_typesudoers uses per-user time stamp files for credential >caching. The timestamp_type option can be used to >specify the type of time stamp record used. It has the >following possible values: > >global A single time stamp record is used for all of a >user's login sessions, regardless of the >terminal or parent process ID. An additional >record is used to serialize password prompts >when sudo is used multiple times in a pipeline, >but this does not affect authentication. > >ppidA single time stamp record is used for all >processes with the same parent process ID >(usually the shell). Commands run from the >same shell (or other common parent process) >will not require a password for >timestamp_timeout minutes (5 by default). >Commands run via sudo with a different parent >process ID, for example from a shell script, >will be authenticated separately. > >tty One time stamp record is used for each >terminal, which means that a user's login >sessions are authenticated separately. If no >terminal is present, the behavior is the same >as ppid. Commands run from the same terminal >will not require a password for >timestamp_timeout minutes (5 by default). FWIW: In the "tty" entry there is: "If no terminal is present, the behavior is the same ass ppid." Could it be that the tmux instances are not recognized as terminal / tty anymore ? In doc/CHANGES: tmux(1): Import version 3.3a [wiz 20230628] -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
recent strange sudo behavior, probably due to /dev/pts
My system is netbsd-10. It was installed around 2003 and has been updated since then, both to each NetBSD stable branch, and to new disks usually via dump/restore and sometimes rsync. Other than the problem I am describing in this message, occasional hangs that I blame on ZFS, and X display glitches, it is working well. I have logged in to ttyE0, and ran "xinit .xsession" which starts xfce4 and I am in an xterm with tmux. I had recently noticed that my system did not have /dev/pts, so I grabbed the line from /etc/fstab on a more recenntly-installed system. I then removed the /dev/ttyp* type entries. This messed up tmux but logging out and starting fresh was ok, and this was not surprising. Now the system is apparently ok execpt for sudo/pkgsrc. I have for a long time had in mk.conf: SU_CMD=sudo /bin/sh -c and "make replace" has invoked sudo, with sudo respecting the don't-ask-for-password timer as documented. Recently this stopped working. After a lot of investigating including writing a quick read/printf program to examine the sudo timestamp files, the problem appears to be that the timestamp records are "TS_PPID" rather than "TS_TTY". The parent is something deep in make, and thus different every time. So this is not really a pkgsrc issue. I have added: Defaults timestamp_type=tty Has anyone else seen sudo refusing to use tty as a timestamp type? sudoers(5) excerpt: timestamp_typesudoers uses per-user time stamp files for credential caching. The timestamp_type option can be used to specify the type of time stamp record used. It has the following possible values: global A single time stamp record is used for all of a user's login sessions, regardless of the terminal or parent process ID. An additional record is used to serialize password prompts when sudo is used multiple times in a pipeline, but this does not affect authentication. ppidA single time stamp record is used for all processes with the same parent process ID (usually the shell). Commands run from the same shell (or other common parent process) will not require a password for timestamp_timeout minutes (5 by default). Commands run via sudo with a different parent process ID, for example from a shell script, will be authenticated separately. tty One time stamp record is used for each terminal, which means that a user's login sessions are authenticated separately. If no terminal is present, the behavior is the same as ppid. Commands run from the same terminal will not require a password for timestamp_timeout minutes (5 by default). kernel The time stamp is stored in the kernel as an attribute of the terminal device. If no terminal is present, the behavior is the same as ppid. Negative timestamp_timeout values are not supported and positive values are limited to a maximum of 60 minutes. This is currently only supported on OpenBSD. The default value is tty. This setting is only supported by version 1.8.21 or higher.
Re: X on 10.0 RC1 is unusable on my laptop
On Thu, Nov 16, 2023 at 10:51:32PM +0100, Rhialto wrote: > On Thu 16 Nov 2023 at 16:44:30 +1030, Brett Lymn wrote: > > On Wed, Nov 15, 2023 at 10:46:13PM +0100, Rhialto wrote: > > > > > > That resulted in both undefined and double defined symbols... > > > so I tried the more oldfashioned way of editing a copy of GENERIC and > > > removing stuff (like the above). Still the same kind of linking errors.. > > > > > > > Did you completely remove the compile directory for you kernel before > > doing the config? > > No, I didn't. I relied on "make depend". Removing the directory does > seem to have made a difference, since there is only one duplicate > definition left now. > > I noticed that there are several files with the same name in old and new > drm. That really seems to confuse config, the Makefile and/or make > depend (after all, the object files end up in the same directory). > Somehow I must have managed, after cleaning up the kernel build > directory, to remove the last wrong piece from the config file. But I > kept getting wrong files in my link so I didn't notice when I finally > had it right. Only after removing all drm* files and rebuilding from > there, I noticed that I seemed to have gotten it right. > > Example of a duplicate: > > ./external/bsd/drm/conf/files.drm:file > external/bsd/drm/dist/bsd-core/drm_memory.c drmbase > ./external/bsd/drm2/drm/files.drmkms:file external/bsd/drm2/drm/drm_memory.c > drmkms > > > So, booting the new kernel gives this driver: > > [ 1.004445] agp0 at pchb0: G4X-family chipset > [ 1.004445] agp0: detected 65020k stolen memory > [ 1.004445] agp0: aperture at 0xc000, size 0x1000 > [ 1.004445] vga0 at pci0 dev 2 function 0: Intel 82GM45 Integrated > Graphics Device (rev. 0x07) > [ 1.004445] wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 > emulation), using wskbd0 > [ 1.004445] wsmux1: connecting to wsdisplay0 > [ 1.004445] i915drm0 at vga0: Mobile Intel<2147483586><2147483566> GM45 > Express Chipset > [ 1.004445] i915drm0: AGP at 0xc000 256MB > [ 1.004445] i915drm0: Initialized i915 1.6.0 20080730 > [ 1.004445] Intel 82GM45 Integrated Graphics Device (miscellaneous > display, revision 0x07) at pci0 dev 2 function 1 not configured > > but the X server with Driver "intel" doesn't see it: > > [41.048] (II) LoadModule: "intel" > [41.048] (II) Loading /usr/X11R7/lib/modules/drivers/intel_drv.so > [41.160] (II) Module intel: vendor="X.Org Foundation" > [41.160]compiled for 1.21.1.9, module version = 2.99.917 > [41.160]Module class: X.Org Video Driver > [41.160]ABI class: X.Org Video Driver, version 25.2 > [41.190] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: > i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, > 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, > Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, > GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 > [41.217] (II) intel: Driver for Intel(R) HD Graphics > [41.217] (II) intel: Driver for Intel(R) Iris(TM) Graphics > [41.217] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics > [41.218] (--) Using wscons driver on /dev/ttyE4 in pcvt compatibility > mode (version 3.32) > [41.218] (--) using VT number 5 > [41.245] (EE) No devices detected. > [41.245] (EE) > Fatal server error: > [41.245] (EE) no screens found(EE) > There are two things that you could verify: 1) That the legacy drm kernel module is also loaded; 2) Since the drm or drmkms use the filesystem (ioctl), the /dev/drm* also exist. You can have an overview of drm and drm-kms with the (not included in the release) manual pages, in the netbsd-xsrc: ./external/mit/libdrm/dist/man/drm.7.rst ./external/mit/libdrm/dist/man/drm-kms.7.rst Note: I have to finish a modification to userconf and config(1). But after that I will give a look to legacy i915drm since I have an integrated Intel GPU too (but I use a discrete radeon, that works in 10.0). -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
