[WIP FAQ13] New section for webcam usage
Hello, Lauries video(1) email to misc@ encouraged me to take this information and try to come up with a proposal to enhance the multimedia faq with information about webcam usage. It's the first time I'm working on a faq article and I don't know about any style guides. I tried to align with the articles already written. Please educate me about the parts I missed. I'm not sure where people working on documentation collaborate. So I'm trying my luck here on tech@. My proposal is online and I'm also inlining it (not as patch for easier consumption): https://codevoid.de/h/wip_webcamfaq13.html I'm sure some parts need refinement / better wording. The part I'm mostly unsure about is how to correctly give the user permissions to the video devices. Most people probably do it the way I described (doas chmod $USER in .xsession). Once it's good enough to get committed, I'll create a proper patch. Any thoughts on it? Thanks in advance, Stefan Using a Webcam Supported Hardware Most webcams today work according to the USB Video Class (UVC) specification, which is supported by the https://man.openbsd.org/uvideo;>uvideo(4) device driver and attaches to the https://man.openbsd.org/video.4;>video(4) device. The manpage lists some supported devices, but there is a good chance that other devices work as well. For example, webcams in Lenovo Thinkpads laptops do usually work. A supported webcam (or other video device) shows up in dmesg like this: uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10 video0 at uvideo0 uvideo1 at uhub0 port 8 configuration 1 interface 2 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10 video1 at uvideo1 You see that an uvideo device was detected and has been attached to video0. This device will be accessible through /dev/video0. Modern laptops sometimes attach a second video device, which is the infrared camera for face recognition. The second camera does not produce a usable video stream. You can find the usable camera with the https://man.openbsd.org/video;>video(1) command: $ video -q -f /dev/video0 video device /dev/video0: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 320x180: 30 320x240: 30 352x288: 30 424x240: 30 640x360: 30 640x480: 30 848x480: 20 960x540: 15 1280x720: 10 controls: brightness, contrast, saturation, hue, gamma, sharpness, white_balance_temperature $ video -q -f /dev/video1 video: /dev/video1 has no usable YUV encodings The usable camera device shows supported resolutions and framerates. Note that the framerates only apply to the uncompressed YUY2 stream. More on that in Recording a webcam stream. Using a webcam as user To use the webcam as regular user, you need to change the device permissions. Only root is allowed to access video devices by default. One way of allowing your user to access the video devices is to change the permissions from ~/.xsession. You can configure https://man.openbsd.org/doas;>doas(1) to perform https://man.openbsd.org/chmod;>chmod(1) as superuser without asking for a password for your user. Then add the following line to your ~/.xsession: doas chown $USER /dev/video0 If you're not using https://man.openbsd.org/xenodm;>xenodm(1) and you are starting your X session with https://man.openbsd.org/startx;>startx(1), you can accomplish the same with https://man.openbsd.org/fbtab;>fbtab(5). Example entry in /etc/fbtab: /dev/ttyC0 0600/dev/video0 Recording a webcam stream This section uses ffplay and ffmpeg from graphics/ffmpeg. To find out what your camera is capable of, run the following command: $ ffplay -f v4l2 -list_formats all -i /dev/video0 [...] [video4linux2,v4l2 @ 0x921f8420800] Compressed: mjpeg : MJPEG : 1280x720 320x180 320x240 352x288 424x240 640x360 640x480 848x480 960x540 [video4linux2,v4l2 @ 0x921f8420800] Raw : yuyv422 : YUYV : 640x480 320x180 320x240 352x288 424x240 640x360 848x480 960x540 1280x720 At the end of the output, you'll find two lines similiar to the two above. The first line shows resolutions supported in the uncompressed YUYV format. The frame rates in this format can be very low. The second line shows the supported MJPEG compressed video resolutions, which deliver much higher framerates (usually 30fps or 60fps). Now try to play the webcam stream. Choose one of the MJPEG resolutions and run: $ ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 [...] Input #0, video4linux2,v4l2, from '/dev/video0':B sq=0B f=0/0 Duration: N/A, start: 1599377893.546533, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 30 fps, 30 tbr, 1000k tbn, 1000k tbc The webcam stream should be displayed. Ffplay also shows the used resolution and the framerate (fps) used. If this works, you can go
Re: [WIP FAQ13] New section for webcam usage
Stefan Hagen wrote: > Using a webcam as user > > > To use the webcam as regular user, you need to change the device > permissions. Only root is allowed to access video devices by default. > > > One way of allowing your user to access the video devices is to change > the permissions from ~/.xsession. You can configure > https://man.openbsd.org/doas;>doas(1) to perform > https://man.openbsd.org/chmod;>chmod(1) as superuser > without asking for a password for your user. > > > Then add the following line to your ~/.xsession: > > > doas chown $USER /dev/video0 > What do you think about adding a group "_video" to the default install and add /dev/video* devices to it with perm. 660. This would allow us to simply instruct users to add their user to group _video to give them access to video devices. Best Regards, Stefan
Re: [WIP FAQ13] New section for webcam usage
Laurence Tratt wrote: > On Sun, Sep 06, 2020 at 07:45:32PM +0200, Stefan Hagen wrote: > I have one tangential comment: > > > Using a webcam as user > > > > To use the webcam as regular user, you need to change the device > > permissions. > > This made me wonder if uvideo should have an equivalent sysctl to audio (i.e. > kern.audio.record)? Most, but I'm not sure all, webcams do display a light to > tell you they're recording, but I can see that there is a security concern > here. An audio device is special in a way that it has playback and recording capabilities in one device. The sysctl is used to allow playback (by default) but not allow recording. Video (as in webcam) is always a recording device, which shouldn't be allowed to access in a default install (in contrast to audio playback). I find the "video" group solution clean and sufficient. I'll send a patch for it, once I've figured out how MAKEDEV works. I say "sufficient", because I believe the best solution would be something like sndiod (vidiod?) that acts as multiplexer and allows multiple applications to access the video stream simultaneously. Best Regards, Stefan
Re: [PATCH] Adding group "video" for /dev/video*
Stefan Hagen wrote:
> Stefan Hagen wrote:
> > Using a webcam as user
> >
> >
> > To use the webcam as regular user, you need to change the device
> > permissions. Only root is allowed to access video devices by default.
> >
> >
> > One way of allowing your user to access the video devices is to change
> > the permissions from ~/.xsession. You can configure
> > https://man.openbsd.org/doas;>doas(1) to perform
> > https://man.openbsd.org/chmod;>chmod(1) as superuser
> > without asking for a password for your user.
> >
> >
> > Then add the following line to your ~/.xsession:
> >
> >
> > doas chown $USER /dev/video0
> >
>
> What do you think about adding a group "_video" to the default install
> and add /dev/video* devices to it with perm. 660. This would allow us
> to simply instruct users to add their user to group _video to give them
> access to video devices.
This patch changes MAKEDEV to generate /dev/video0..n with permission
660 and group "video". It also adds the group "video" with GID 46 to
/etc/groups.
OK?
Best Regards,
Stefan
Index: etc//MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 MAKEDEV.common
--- etc//MAKEDEV.common 6 Jul 2020 06:11:26 - 1.111
+++ etc//MAKEDEV.common 8 Sep 2020 20:22:09 -
@@ -428,7 +428,7 @@ __devitem(au, audio*, Audio devices,audi
_mkdev(au, audio*, {-M audio$U c major_au_c $U 660 _sndiop
M audioctl$Uc major_au_c Add($U, 192) 660 _sndiop-})dnl
__devitem(vi, video*, Video V4L2 devices,video)dnl
-_mkdev(vi, video*, {-M video$U c major_vi_c $U 600
+_mkdev(vi, video*, {-M video$U c major_vi_c $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"-})dnl
__devitem(asc, asc*, ASC Audio device)dnl
_mkdev(asc, asc*, {-M asc$U major_asc_c 0-})dnl
Index: etc//group
===
RCS file: /cvs/src/etc/group,v
retrieving revision 1.94
diff -u -p -u -p -r1.94 group
--- etc//group 28 Jan 2020 16:51:03 - 1.94
+++ etc//group 8 Sep 2020 20:22:09 -
@@ -21,6 +21,7 @@ _fingerd:*:33:
_sshagnt:*:34:
_x11:*:35:
utmp:*:45:
+video:*:46:
_unwind:*:48:
_switchd:*:49:
_traceroute:*:50:
Index: etc//etc.alpha/MAKEDEV
===
RCS file: /cvs/src/etc/etc.alpha/MAKEDEV,v
retrieving revision 1.215
diff -u -p -u -p -r1.215 MAKEDEV
--- etc//etc.alpha/MAKEDEV 6 Jul 2020 06:12:37 - 1.215
+++ etc//etc.alpha/MAKEDEV 8 Sep 2020 20:22:09 -
@@ -260,7 +260,7 @@ vscsi*)
;;
video*)
- M video$U c 44 $U 600
+ M video$U c 44 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.amd64/MAKEDEV
===
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 MAKEDEV
--- etc//etc.amd64/MAKEDEV 6 Jul 2020 06:12:37 - 1.131
+++ etc//etc.amd64/MAKEDEV 8 Sep 2020 20:22:09 -
@@ -272,7 +272,7 @@ vmm)
;;
video*)
- M video$U c 44 $U 600
+ M video$U c 44 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.arm64/MAKEDEV
===
RCS file: /cvs/src/etc/etc.arm64/MAKEDEV,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 MAKEDEV
--- etc//etc.arm64/MAKEDEV 6 Jul 2020 06:12:37 - 1.18
+++ etc//etc.arm64/MAKEDEV 8 Sep 2020 20:22:10 -
@@ -248,7 +248,7 @@ vscsi*)
;;
video*)
- M video$U c 44 $U 600
+ M video$U c 44 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.armv7/MAKEDEV
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 MAKEDEV
--- etc//etc.armv7/MAKEDEV 6 Jul 2020 06:12:37 - 1.35
+++ etc//etc.armv7/MAKEDEV 8 Sep 2020 20:22:10 -
@@ -244,7 +244,7 @@ vscsi*)
;;
video*)
- M video$U c 38 $U 600
+ M video$U c 38 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.hppa/MAKEDEV
===
RCS file: /cvs/src/etc/etc.hppa/MAKEDEV,v
retrieving revision 1.154
diff -u -p -u -p -r1.154 MAKEDEV
--- etc//etc.hppa/MAKEDEV 6 Jul 2020 06:12:37 - 1.154
+++ etc//etc.hppa/MAKEDEV 8 Sep 2020 20:22:10 -
@@ -243,7
Re: match on more ure(4) devices
Hi Jonathan,
Jonathan Gray wrote:
> match on additional device ids from lenovo windows driver
> https://download.lenovo.com/consumer/options/thinkpad_usb-c_dock_gen2_drivers_v1.0.3.03241.exe
> and linux driver
[...]
> + { USB_VENDOR_LENOVO, USB_PRODUCT_LENOVO_RTL8153B_2 },
[...]
This is an audio device in the Lenovo Thunderbolt 3 Workstation Dock Gen 2.
I've sent a bug report with dmesg to bugs@ for it an hour ago.
This is the windows driver for this dock. If you want to cross check.
https://download.lenovo.com/consumer/options/thinkpad_tbt3_gen2_ws_dock_driver_10016.exe
Best Regards,
Stefan
[PATCH] faq13, Using a Webcam
Hello, After some discussions in the WIP thread, I decided to send a patch without the part in question. So here is the "Using a Webcam" chapter which does only mention that it's necessary to set permissions of /dev/video* to the user. I leaves out the details about how to do it best. If there are new developments, like a video group or a sysctl video.record knob, I'll send delta patches to describe the behavior. OK? Best Regards, Stefan Index: faq/faq13.html === RCS file: /cvs/www/faq/faq13.html,v retrieving revision 1.220 diff -u -p -u -p -r1.220 faq13.html --- faq/faq13.html 19 May 2020 02:01:48 - 1.220 +++ faq/faq13.html 19 Sep 2020 17:26:38 - @@ -66,6 +66,7 @@ FAQ - Multimedia Choosing the Default Audio Device Debugging Audio Problems Using MIDI Instruments + Using a Webcam
Re: [PATCH] Adding group "video" for /dev/video*
Stefan Hagen wrote: > This patch changes MAKEDEV to generate /dev/video0..n with permission > 660 and group "video". It also adds the group "video" with GID 46 to > /etc/groups. > > OK? *ping* I think this one got lost in the thread. Best Regards, Stefan
Xterm close delay when child processes exist
Hello,
xterm has an annoying delay when it's being close by the window manager
when child processes exist.
Test 1:
xterm -e "sh"
Now hit the "X" button or whatever your window manager provides to send a
window delete event. Xterm should close almost instantly.
Test 2:
xterm -e "sh -c sh"
You can execute this, or just open xterm and open another shell inside.
Now close it again. In this situation it takes about 1 second to close.
Window deletion triggers do_hangup(), which invokes a kill(-pid, SIGHUP)
and then waits around one second before it quits. I couldn't figure out
what it does in this time. But ktrace hints that it ran into a Sleep()
statement because the delay is right after a select and fd_set, which is
only called in Sleep().
I looked and the xterm menu Quit function and found that it does something
slightly different than than window delete. It also sends kill(-pid,SIGHUP),
but then immediately exits.
Handle_send_signal and Cleanup are doing the same thing, except Cleanup
calls exit right afterwards.
My naive assumtion is, that this would also be the right behavior on
window deletion.
Index: app/xterm/menu.c
===
RCS file: /cvs/xenocara/app/xterm/menu.c,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 menu.c
--- app/xterm/menu.c20 Jan 2020 21:03:35 - 1.30
+++ app/xterm/menu.c8 Nov 2020 15:49:08 -
@@ -1422,7 +1422,7 @@ do_hangup(Widget gw,
XtPointer closure GCC_UNUSED,
XtPointer data GCC_UNUSED)
{
-handle_send_signal(gw, SIGHUP);
+Cleanup(SIGHUP);
}
/* ARGSUSED */
Re: Xterm close delay when child processes exist
Bryan Steele wrote: > This would be better off sent upstream, not maintained locally in > OpenBSD. > > https://invisible-island.net/xterm/xterm.faq.html#report_bugs Done. Thanks. Best Regards, Stefan
Hiding the vim user in amdgpu_vcn.c (typo in comment)
Hi, I can totally relate to this one. Found after a conversation about muscle memory and grepping the source tree for ":wq". Best Regards, Stefan Index: ./sys/dev/pci/drm/amd/amdgpu/amdgpu_vcn.c === RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_vcn.c,v retrieving revision 1.5 diff -u -p -u -p -r1.5 amdgpu_vcn.c --- ./sys/dev/pci/drm/amd/amdgpu/amdgpu_vcn.c 8 Jun 2020 04:47:59 - 1.5 +++ ./sys/dev/pci/drm/amd/amdgpu/amdgpu_vcn.c 5 Jan 2021 12:13:51 - @@ -128,7 +128,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_dev /* Bit 20-23, it is encode major and non-zero for new naming convention. * This field is part of version minor and DRM_DISABLED_FLAG in old naming -* convention. Since the l:wq!atest version minor is 0x5B and DRM_DISABLED_FLAG +* convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG * is zero in old naming convention, this field is always zero so far. * These four bits are used to tell which naming convention is present. */
Re: [PATCH] faq13, Using a Webcam
Stefan Hagen wrote: > If there are new developments, like a video group or a sysctl video.record > knob, I'll send delta patches to describe the behavior. I've updated the patch to cover the kern.video.record knob. I also used # instead of $ doas in code blocks. Index: faq/faq13.html === RCS file: /cvs/www/faq/faq13.html,v retrieving revision 1.221 diff -u -p -u -p -r1.221 faq13.html --- faq/faq13.html 26 Sep 2020 22:11:00 - 1.221 +++ faq/faq13.html 3 Jan 2021 11:49:50 - @@ -66,6 +66,7 @@ FAQ - Multimedia Choosing the Default Audio Device Debugging Audio Problems Using MIDI Instruments + Using a Webcam
[patch] Add support for Wacom One (CTL-472) to uwacom(4)
Hello,
I managed to get the Wacom One, aka CTL-472 working. It's a small
graphics tablet with no extra buttons. I's more recent than the already
supported CTL-490.
Changes:
- It reports little endian values for X / Y coordinates
- 0x0202 needs to be written to feature report ID 2 before it starts
sending interrupts (I got this hint from the graphire tablet support
in the netbsd uhidev driver)
- The reported X/Y resolution is twice as big
- The button 0 workaround via pressure is not necessary
Relevant for testing:
There is a bug, that was already there before. The tablet must be
connected when Xorg is starting. Otherwise the tablet resolution is not
correctly mapped to the screen resolution.
This is my first contribution in the device-driver area.
What do you think about it?
Best Regards,
Stefan
Index: sys/dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.752
diff -u -p -u -p -r1.752 usbdevs.h
--- sys/dev/usb/usbdevs.h 18 May 2021 14:23:53 - 1.752
+++ sys/dev/usb/usbdevs.h 6 Jun 2021 17:27:24 -
@@ -4582,6 +4582,7 @@
#defineUSB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015 /* Graphire4
Classic A6 */
#defineUSB_PRODUCT_WACOM_INTUOSA5 0x0021 /* Intuos A5 */
#defineUSB_PRODUCT_WACOM_INTUOS_DRAW 0x033b /* Intuos Draw
(CTL-490) */
+#defineUSB_PRODUCT_WACOM_ONE_S 0x037a /* One
(CTL-472) */
#defineUSB_PRODUCT_WACOM_INTUOS_PRO_S 0x0392 /* Intuos Pro S
*/
/* WAGO Kontakttechnik products */
Index: sys/dev/usb/uwacom.c
===
RCS file: /cvs/src/sys/dev/usb/uwacom.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 uwacom.c
--- sys/dev/usb/uwacom.c23 Aug 2020 11:08:02 - 1.2
+++ sys/dev/usb/uwacom.c6 Jun 2021 17:27:24 -
@@ -39,6 +39,8 @@ struct uwacom_softc {
struct uhidev sc_hdev;
struct hidmssc_ms;
struct hid_location sc_loc_tip_press;
+ int sc_big_endian;
+ int sc_use_pressure;
};
struct cfdriver uwacom_cd = {
@@ -47,7 +49,8 @@ struct cfdriver uwacom_cd = {
const struct usb_devno uwacom_devs[] = {
- { USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW }
+ { USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOS_DRAW },
+ { USB_VENDOR_WACOM, USB_PRODUCT_WACOM_ONE_S }
};
intuwacom_match(struct device *, void *, void *);
@@ -102,6 +105,8 @@ uwacom_attach(struct device *parent, str
sc->sc_hdev.sc_parent = uha->parent;
sc->sc_hdev.sc_udev = uaa->device;
sc->sc_hdev.sc_report_id = uha->reportid;
+ sc->sc_big_endian = 0;
+ sc->sc_use_pressure = 0;
usbd_set_idle(uha->parent->sc_udev, uha->parent->sc_ifaceno, 0, 0);
@@ -121,9 +126,25 @@ uwacom_attach(struct device *parent, str
ms->sc_loc_y.size = 16;
ms->sc_tsscale.minx = 0;
- ms->sc_tsscale.maxx = 7600;
ms->sc_tsscale.miny = 0;
- ms->sc_tsscale.maxy = 4750;
+ if (uha->uaa->product == USB_PRODUCT_WACOM_ONE_S) {
+ static uByte reportbuf[2];
+ reportbuf[0] = 0x02;
+ reportbuf[1] = 0x02;
+ uhidev_set_report(uha->parent, UHID_FEATURE_REPORT, 2,
+ , 2);
+ ms->sc_tsscale.maxx = 15200;
+ ms->sc_tsscale.maxy = 9500;
+ }
+
+ if (uha->uaa->product == USB_PRODUCT_WACOM_INTUOS_DRAW) {
+ sc->sc_big_endian = 1;
+ sc->sc_use_pressure = 1;
+ sc->sc_loc_tip_press.pos = 43;
+ sc->sc_loc_tip_press.size = 8;
+ ms->sc_tsscale.maxx = 7600;
+ ms->sc_tsscale.maxy = 4750;
+ }
ms->sc_loc_btn[0].pos = 0;
ms->sc_loc_btn[0].size = 1;
@@ -132,9 +153,6 @@ uwacom_attach(struct device *parent, str
ms->sc_loc_btn[2].pos = 2;
ms->sc_loc_btn[2].size = 1;
- sc->sc_loc_tip_press.pos = 43;
- sc->sc_loc_tip_press.size = 8;
-
hidms_attach(ms, _accessops);
}
@@ -163,19 +181,26 @@ uwacom_intr(struct uhidev *addr, void *b
if ((data[0] & 0xf0) == 0xc0)
return;
- x = be16toh(hid_get_data(data, len, >sc_loc_x));
- y = be16toh(hid_get_data(data, len, >sc_loc_y));
- pressure = hid_get_data(data, len, >sc_loc_tip_press);
+ if (sc->sc_big_endian == 1) {
+ x = be16toh(hid_get_data(data, len, >sc_loc_x));
+ y = be16toh(hid_get_data(data, len, >sc_loc_y));
+ } else {
+ x = le16toh(hid_get_data(data, len, >sc_loc_x));
+ y = le16toh(hid_get_data(data, len, >sc_loc_y));
+ }
for (i = 0; i < ms->sc_num_buttons; i++)
if (hid_get_data(data, len, >sc_loc_btn[i]))
buttons
uwacom: reduce tip pressure for click activation
Hi, I'm using a Wacom CTL-490 to draw on virtual whiteboards in online meetings. Compared to linux/windows, it needs a lot of pressure to draw something on OpenBSD. This makes writing pretty hard. In OpenBSD, a tip-pressure of >10 is required to activate button 0. I'm not sure why this number was chosen. I assumed that it might be because pressure reporting could be jittering. I've set it to >0 for testing and I couldn't be happier. I tested it with two pens and didn't experience any false-activation. Would this patch okay with you? uwacom author on cc. Best Regards, Stefan Index: sys/dev/usb/uwacom.c === RCS file: /cvs/src/sys/dev/usb/uwacom.c,v retrieving revision 1.2 diff -u -p -u -p -r1.2 uwacom.c --- sys/dev/usb/uwacom.c23 Aug 2020 11:08:02 - 1.2 +++ sys/dev/usb/uwacom.c3 Jun 2021 14:40:37 - @@ -172,7 +172,7 @@ uwacom_intr(struct uhidev *addr, void *b buttons |= (1 << i); /* button 0 reporting is flaky, use tip pressure for it */ - if (pressure >10) + if (pressure) buttons |= 1; else buttons &= ~1;
Re: uwacom: reduce tip pressure for click activation
Peter J. Philipp wrote: > I have a Wacom Intuos. Which one? > I found that I could not write anything as good as with the pressure > having a higher threshold ie. the original driver. Can you be more specific? Did you have false activations without touching the tablet? The pressure sensor is used because the button activation is flaky. See comment in the code. To verify this, I've taken out the pressure code and checked when button 0 usually activates. This correlates with pressure 1. That was another indicator that my patch would make the tablet behave more as it should. > I used gimp to write with the wacom which is the utility I use to draw > when I do draw with the Intuos. I'm using xournal. I tried gimp as well. Works very well for me with the patched setting. I can, however, understand that when you're used to having to push hard, a lighter setting might feel off. Best Regards, Stefan
Re: uwacom: reduce tip pressure for click activation
James Cook wrote: > This is what appears in dmesg when I plug it in: > > uhidev0 at uhub0 port 9 configuration 1 interface 0 "Wacom Co.,Ltd. > Intuos BT S" rev 2.00/1.07 addr 4 That doesn't work. Currently _only_ the CTL-490 is supported. I have an Intuos 4 an Intuos ONE (CTL-472) here. I added the device IDs and the wacom driver attaches, but they don't work. They still behave like a mouse (with relative positioning). These two lines appear when the driver is attaching: *uwacom0 at uhidev2 reportid 16: 3 buttons *wsmouse1 at uwacom0 mux 0 I'll give it another spin over the weekend. Maybe I can figure out what the difference is. Best Regards, Stefan
Re: uwacom: reduce tip pressure for click activation
Peter J. Philipp wrote: > On Thu, Jun 03, 2021 at 08:06:06PM +0200, Stefan Hagen wrote: >> Which one? > > It didn't say in the dmesg if I recall correctly, luckily I found the > packaging. CTL-490 DW-S. Same model here. I just wanted to make sure that the driver is actually used in your case. It only supports this one. > I found it very hard to just write "This is a test" seemed harder > to do with your patch. The lack of pressure on the pen caused it to > miswrite. Feel exactly the opposite way here. > Maybe I'm just used to the press Hmm, well don't let me stop your > patch, I just wanted to give feedback on how I perceived it. Thanks. Maybe more feedback will come. Best Regards, Stefan
Re: [patch] Add support for Wacom One (CTL-472) to uwacom(4)
I'm still happily using this diff with the CTL-472. Ping? Stefan Hagen wrote: > Hello, > > I managed to get the Wacom One, aka CTL-472 working. It's a small > graphics tablet with no extra buttons. I's more recent than the already > supported CTL-490. > > Changes: > - It reports little endian values for X / Y coordinates > - 0x0202 needs to be written to feature report ID 2 before it starts > sending interrupts (I got this hint from the graphire tablet support > in the netbsd uhidev driver) > - The reported X/Y resolution is twice as big > - The button 0 workaround via pressure is not necessary > > Relevant for testing: > There is a bug, that was already there before. The tablet must be > connected when Xorg is starting. Otherwise the tablet resolution is not > correctly mapped to the screen resolution. > > This is my first contribution in the device-driver area. > What do you think about it? > > Best Regards, > Stefan
[patch] bring back kern.video.record to faq13
Hello, just a reminder to bring kern.video.record back into faq13 before the 6.9 release. Best Regards, Stefan Index: faq/faq13.html === RCS file: /cvs/www/faq/faq13.html,v retrieving revision 1.225 diff -u -p -u -p -r1.225 faq13.html --- faq/faq13.html 24 Feb 2021 00:19:17 - 1.225 +++ faq/faq13.html 11 Apr 2021 07:52:30 - @@ -494,7 +494,7 @@ $ midicat -q midi/0 -q midithru/0 Using a Webcam - + Supported Hardware Many webcams following the USB Video Class (UVC) specification are supported
Re: updated patch for iwx(4) Tx aggregation
Dave Voutila wrote: > > Stefan Sperling writes: > > > Here is another attempt at adding Tx aggregation to iwx(4). > > This patch is based on the latest state in CVS (if_iwx.c r1.107, which > > I have committed a minute ago). Sync your tree before applying this patch. > > > > Compared to previous iterations of this patch, I have fixed bugs which > > caused fatal firmware errors and which made traffic stall after roaming. > > > > This patch could still make 7.0 release if it gets sufficient test coverage. > > Please run with this and report any regressions. Thanks! > > > > So far, tested by me on AX200 and AX201 against a Pepwave 11ac AP. > > I have so far not seen any fatal firmware errors, and roaming between 2GHz > > and 5GHz channels offered by the same AP seems to work reliably. > > Throughput goes up to 100 Mbit/s max. > > Looking good so far on my new iwx pcie device. Am able to get 50/25 > Mbit/s up/down via speedtest-cli. Improvement over my previous speeds > from where this device is located. > > Box it came in said it's a "Ubit WIE7265 AX200NGW T2", dmesg reports: > > iwx0 at pci13 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix > iwx0: hw rev 0x340, fw ver 63.c04f3485.0, address b0:7d:64:86:b7:80 > > Will try on my X13 later tonight or this weekend. The above device is in > a stationary machine, so I can't test moving the house around with it. I tested this patch on my x13 gen1 amd. It comes with the exact same card: iwx0 at pci3 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix iwx0: hw rev 0x340, fw ver 63.c04f3485.0, address 70:9c:d1:b1:2d:bc All results show the best out of three runs: Reference before patch: # Speedtest from my usual working spot Ping: 37.837 ms Download: 22.62 Mbit/s Upload: 6.63 Mbit/s After patching: # speedtest-cli from my usual working spot Ping: 11.269 ms Download: 28.54 Mbit/s Upload: 12.46 Mbit/s Downloading a 200MB file from my local NFS server averages at 3.3MB/s Uploading a 200MB file to my local NFS server averages at 1.71MB/s Measured with nload(1) # speedtest-cli 20cm next to my AP (Unifi AC Pro) Ping: 13.008 ms Download: 28.65 Mbit/s Upload: 10.19 Mbit/s # speedtest-cli from the other room Ping: 11.456 ms Download: 10.73 Mbit/s Upload: 4.26 Mbit/s # Compared with my x230 (iwn) from my usual working spot Ping: 49.36 ms Download: 45.39 Mbit/s Upload: 35.69 Mbit/s Best regards, Stefan
Re: updated patch for iwx(4) Tx aggregation
Stefan Sperling wrote: > On Sat, Sep 11, 2021 at 02:04:32PM +0200, Stefan Sperling wrote: > > On Fri, Sep 10, 2021 at 06:49:49PM +0200, Stefan Sperling wrote: > > > Here is another attempt at adding Tx aggregation to iwx(4). > > > This patch is based on the latest state in CVS (if_iwx.c r1.107, which > > > I have committed a minute ago). Sync your tree before applying this patch. > > > > > > Compared to previous iterations of this patch, I have fixed bugs which > > > caused fatal firmware errors and which made traffic stall after roaming. > > > > > > This patch could still make 7.0 release if it gets sufficient test > > > coverage. > > > Please run with this and report any regressions. Thanks! > > > > > > So far, tested by me on AX200 and AX201 against a Pepwave 11ac AP. > > > I have so far not seen any fatal firmware errors, and roaming between 2GHz > > > and 5GHz channels offered by the same AP seems to work reliably. > > > Throughput goes up to 100 Mbit/s max. > > > > The previous version had a problem where it did not take frames > > off the Tx ring when they were done. It is possible that this > > could lead to memory corruption (seen by mlarkin). > > > > Please run this updated patch instead. > > > > And please enable 'ifconfig iwx0 debug' while testing this patch. > > Problem reports will be a lot more useful with debug enabled :) > > I have extracted two important fixes from this patch which have now > been committed to -current. > Below is a newly rebased diff which contains the remaining changes. > > To prevent merge conflicts when updating, I would recommend to remove > changes made by the previous patch, update the source tree, and apply > the patch below on top of this clean updated tree. I'm running with this since you posted it. No issues so far. Best regards, Stefan
Re: updated patch for iwx(4) Tx aggregation
Stefan Sperling wrote: > On Fri, Sep 10, 2021 at 06:49:49PM +0200, Stefan Sperling wrote: > > Here is another attempt at adding Tx aggregation to iwx(4). > > This patch is based on the latest state in CVS (if_iwx.c r1.107, which > > I have committed a minute ago). Sync your tree before applying this patch. > > > > Compared to previous iterations of this patch, I have fixed bugs which > > caused fatal firmware errors and which made traffic stall after roaming. > > > > This patch could still make 7.0 release if it gets sufficient test coverage. > > Please run with this and report any regressions. Thanks! > > > > So far, tested by me on AX200 and AX201 against a Pepwave 11ac AP. > > I have so far not seen any fatal firmware errors, and roaming between 2GHz > > and 5GHz channels offered by the same AP seems to work reliably. > > Throughput goes up to 100 Mbit/s max. > > The previous version had a problem where it did not take frames > off the Tx ring when they were done. It is possible that this > could lead to memory corruption (seen by mlarkin). > > Please run this updated patch instead. Oh, it's fast now... $ speedtest-cli --simple Ping: 16.436 ms Download: 81.99 Mbit/s Upload: 31.18 Mbit/s I'll keep it in with debug enabled. Best regards, Stefan
Re: updated patch for iwx(4) Tx aggregation
Stefan Hagen wrote: > Stefan Sperling wrote: > > On Fri, Sep 10, 2021 at 06:49:49PM +0200, Stefan Sperling wrote: > > > Here is another attempt at adding Tx aggregation to iwx(4). > > > This patch is based on the latest state in CVS (if_iwx.c r1.107, which > > > I have committed a minute ago). Sync your tree before applying this patch. > > > > > > Compared to previous iterations of this patch, I have fixed bugs which > > > caused fatal firmware errors and which made traffic stall after roaming. > > > > > > This patch could still make 7.0 release if it gets sufficient test > > > coverage. > > > Please run with this and report any regressions. Thanks! > > > > > > So far, tested by me on AX200 and AX201 against a Pepwave 11ac AP. > > > I have so far not seen any fatal firmware errors, and roaming between 2GHz > > > and 5GHz channels offered by the same AP seems to work reliably. > > > Throughput goes up to 100 Mbit/s max. > > > > The previous version had a problem where it did not take frames > > off the Tx ring when they were done. It is possible that this > > could lead to memory corruption (seen by mlarkin). > > > > Please run this updated patch instead. > > Oh, it's fast now... > > $ speedtest-cli --simple > Ping: 16.436 ms > Download: 81.99 Mbit/s > Upload: 31.18 Mbit/s > > I'll keep it in with debug enabled. No issues... Just further testing while a transfer from an NFS share was running. I was walking around until the connection stalled and came back. (around 15:44) It roamed fine between APs and reassociated three times. At 15:52:17 is a suspend + wakeup, which also worked. I can't test hibernation (amdgpu issues) The transfer rates were stable and moved up to 7.4MB/s depending on the distance to the next AP. This diff improves performance greatly. No fatal errors in this test. Best regards, Stefan /var/log/messsages with iwx debug: Sep 11 15:07:38 x13 /bsd: OpenBSD 7.0-beta (GENERIC.MP) #1: Sat Sep 11 15:05:11 CEST 2021 Sep 11 15:07:38 x13 /bsd: s...@x13.home.codevoid.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP Sep 11 15:07:38 x13 /bsd: real mem = 14722068480 (14040MB) Sep 11 15:07:38 x13 /bsd: avail mem = 14259879936 (13599MB) Sep 11 15:07:38 x13 /bsd: random: good seed from bootblocks Sep 11 15:07:38 x13 /bsd: mpath0 at root Sep 11 15:07:38 x13 /bsd: scsibus0 at mpath0: 256 targets Sep 11 15:07:38 x13 /bsd: mainbus0 at root Sep 11 15:07:38 x13 /bsd: bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf711000 (68 entries) Sep 11 15:07:38 x13 /bsd: bios0: vendor LENOVO version "R1CET66W(1.35 )" date 07/30/2021 Sep 11 15:07:38 x13 /bsd: bios0: LENOVO 20UGS00800 Sep 11 15:07:38 x13 /bsd: acpi0 at bios0: ACPI 6.3 Sep 11 15:07:38 x13 /bsd: acpi0: sleep states S0 S3 S4 S5 Sep 11 15:07:38 x13 /bsd: acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT TPM2 SSDT POAT BATB HPET APIC MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT SSDT Sep 11 15:07:38 x13 /bsd: acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) Sep 11 15:07:38 x13 /bsd: acpitimer0 at acpi0: 3579545 Hz, 32 bits Sep 11 15:07:38 x13 /bsd: acpihpet0 at acpi0: 14318180 Hz Sep 11 15:07:38 x13 /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Sep 11 15:07:38 x13 /bsd: cpu0 at mainbus0: apid 0 (boot processor) Sep 11 15:07:38 x13 /bsd: cpu0: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1697.07 MHz, 17-60-01 Sep 11 15:07:38 x13 /bsd: cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES Sep 11 15:07:38 x13 /bsd: cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache Sep 11 15:07:38 x13 /bsd: cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative Sep 11 15:07:38 x13 /bsd: cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative Sep 11 15:07:38 x13 /bsd: cpu0: smt 0, core 0, package 0 Sep 11 15:07:38 x13 /bsd: mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges Sep 11 15:07:38 x13 /bsd: cpu0: apic clock running at 99MHz Sep 11 15:07:38 x13 /bsd: cpu0: mwait min=64, max=64, C-substates=1.1, IBE Sep 11 15:07:38 x13 /bsd: cpu1 at mainbus0: apid 1 (application processor) Sep 11 15:07:38 x13 /bsd: cpu1: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1696.81 MHz, 17-60-01 Sep 11 15:07:38 x13 /bsd: cpu1: FPU,VME,DE,PSE,TSC,MS
Re: updated patch for iwx(4) Tx aggregation
Stefan Sperling wrote: > On Sat, Sep 11, 2021 at 04:29:58PM +0200, Stefan Hagen wrote: > > Sep 11 15:52:39 x13 /bsd: iwx0: associated with e6:63:da:7e:f8:24 ssid > > "DiscMate" channel 36 start MCS 0 long preamble short slot time HT enabled > > Sep 11 15:52:39 x13 /bsd: iwx0: missed beacon threshold set to 30 beacons, > > beacon interval is 100 TU > > Sep 11 15:52:39 x13 /bsd: iwx0: received msg 3/4 of the 4-way handshake > > from e6:63:da:7e:f8:24 > > Sep 11 15:52:39 x13 /bsd: iwx0: sending msg 4/4 of the 4-way handshake to > > e6:63:da:7e:f8:24 > > Sep 11 15:52:39 x13 /bsd: iwx0: RUN -> ASSOC > > Looks like the AP sent a dis-assoc frame here. I wonder why. > Are your access points configured for band steering, perhaps? > Or are there any other similar fancy "non-standard" enhancements > enabled on the AP side? I'm not sure. Because I see conflicting options here: On each AP individually: - Band Steering: off In the controller software: - [x] Connect high performance clients to 5 GHz only (beta) There's no documentation about it. The internet describes it as "super-duper-band-steering" that forces "modern devices" to 5G or no connectivity at all. I will turn this off and see if the dis-assoc disappears. > > Sep 11 15:52:39 x13 /bsd: iwx0: sending assoc_req to e6:63:da:7e:f8:24 on > > channel 36 mode 11n > > Sep 11 15:52:39 x13 /bsd: iwx0: ASSOC -> RUN > > Sep 11 15:52:39 x13 /bsd: iwx0: associated with e6:63:da:7e:f8:24 ssid > > "DiscMate" channel 36 start MCS 0 long preamble short slot time HT enabled > > Sep 11 15:52:39 x13 /bsd: iwx0: missed beacon threshold set to 30 beacons, > > beacon interval is 100 TU > > I suspect we don't handle RUN -> ASSOC -> RUN transitions correctly. > This somehow results in the following fw error and the already known: > "iwx0: could not remove MAC context (error 35) > This error has been reported before (e.g. by jmc). > So it's not a regression. > > This is an interesting trace. Thanks! Happy to help! Best regards, Stefan
Re: iwx(4) 40MHz channel support
Stefan Sperling wrote: > This patch adds support for 40MHz channels to iwx(4). > > Please sync your source tree before attempting to apply this patch. > I have committed some changes to this driver today which this patch > is based on. > > Works for me on AX200/AX201. Does anyone else want to do a pre-commit test? *jaw drops to floor* I double checked. There was no cable connected. [x13](0)(~)$ iperf3 -c 192.168.1.20 Connecting to host 192.168.1.20, port 5201 [ 5] local 192.168.1.226 port 40211 connected to 192.168.1.20 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 20.7 MBytes 173 Mbits/sec [ 5] 1.00-2.00 sec 24.3 MBytes 204 Mbits/sec [ 5] 2.00-3.00 sec 24.6 MBytes 206 Mbits/sec [ 5] 3.00-4.00 sec 24.6 MBytes 207 Mbits/sec [ 5] 4.00-5.00 sec 24.6 MBytes 206 Mbits/sec [ 5] 5.00-6.00 sec 24.8 MBytes 208 Mbits/sec [ 5] 6.00-7.00 sec 24.8 MBytes 208 Mbits/sec [ 5] 7.00-8.00 sec 24.6 MBytes 207 Mbits/sec [ 5] 8.00-9.00 sec 24.8 MBytes 208 Mbits/sec [ 5] 9.00-10.00 sec 24.8 MBytes 209 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 243 MBytes 203 Mbits/sec sender [ 5] 0.00-10.02 sec 243 MBytes 203 Mbits/sec receiver iperf Done. [x13](0)(~)$ iperf3 -R -c 192.168.1.20 Connecting to host 192.168.1.20, port 5201 Reverse mode, remote host 192.168.1.20 is sending [ 5] local 192.168.1.226 port 19869 connected to 192.168.1.20 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 7.21 MBytes 60.5 Mbits/sec [ 5] 1.00-2.00 sec 12.7 MBytes 106 Mbits/sec [ 5] 2.00-3.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 3.00-4.00 sec 17.5 MBytes 147 Mbits/sec [ 5] 4.00-5.00 sec 18.6 MBytes 156 Mbits/sec [ 5] 5.00-6.00 sec 19.3 MBytes 162 Mbits/sec [ 5] 6.00-7.00 sec 19.8 MBytes 166 Mbits/sec [ 5] 7.00-8.00 sec 20.2 MBytes 170 Mbits/sec [ 5] 8.00-9.00 sec 20.9 MBytes 175 Mbits/sec [ 5] 9.00-10.00 sec 21.0 MBytes 176 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 173 MBytes 145 Mbits/sec0 sender [ 5] 0.00-10.00 sec 173 MBytes 145 Mbits/sec receiver iperf Done. This ramp up time is reproducible. It always starts slower in the first 1 or 2 seconds and then ramps up to full speed. More testing + log in case you want to skim through it. Test 1: Walking around and got it to roam to the next AP Test 2: Going into suspend for ~30sec with running NFS transfer, resuming, NFS transfer continues Test 3: Going into suspend, walk to the next room (AP change), resuming, NFS transfer continues [...] Oct 14 08:23:41 x13 /bsd: iwx0 at pci3 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix Oct 14 08:23:41 x13 /bsd: iwx0: hw rev 0x340, fw ver 63.c04f3485.0, address 70:9c:d1:b1:2d:bc [...] Oct 14 08:23:41 x13 /bsd: iwx0: begin active scan Oct 14 08:23:41 x13 /bsd: iwx0: INIT -> SCAN Oct 14 08:23:41 x13 /bsd: iwx0: SCAN -> INIT Oct 14 08:23:41 x13 /bsd: iwx0: begin active scan Oct 14 08:23:41 x13 /bsd: iwx0: INIT -> SCAN Oct 14 08:23:41 x13 /bsd: iwx0: end active scan Oct 14 08:23:41 x13 /bsd: iwx0: best AP e0:63:da:7e:f8:24 "DiscMate" score 75 Oct 14 08:23:41 x13 /bsd: iwx0: switching to network "DiscMate" Oct 14 08:23:41 x13 /bsd: iwx0: + 18:e8:29:57:3d:061 +27 54M ess privacy rsn "DiscMate" Oct 14 08:23:41 x13 /bsd: iwx0: + 18:e8:29:58:3d:06 36 +29 54M ess privacy rsn "DiscMate" Oct 14 08:23:41 x13 /bsd: iwx0: - 1c:3a:de:74:c2:50 13 +13 54M ess privacy rsn "HZN242371510"! Oct 14 08:23:41 x13 /bsd: iwx0: - 1e:e8:29:57:3d:061 +29 54M ess privacy rsn ""! Oct 14 08:23:41 x13 /bsd: iwx0: - 1e:e8:29:58:3d:06 36 +29 54M ess privacy rsn ""! Oct 14 08:23:41 x13 /bsd: iwx0: - 2c:91:ab:82:87:43 36+8 54M ess privacy rsn "FRITZ!Box 6591 Cable AQ"! Oct 14 08:23:41 x13 /bsd: iwx0: - 2c:91:ab:82:87:446 +15 54M ess privacy rsn "FRITZ!Box 6591 Cable AQ"! Oct 14 08:23:41 x13 /bsd: iwx0: - 38:10:d5:f7:c4:b61 +17 54M ess privacy rsn "FRITZ!Box 7412"! Oct 14 08:23:41 x13 /bsd: iwx0: - 38:43:7d:a5:ea:43 44 +17 54M ess privacy rsn "UPC5673586"! Oct 14 08:23:41 x13 /bsd: iwx0: - 38:43:7d:a5:ea:691 +16 54M ess privacy rsn "UPC5673586"! Oct 14 08:23:41 x13 /bsd: iwx0: - 3a:9d:92:ad:3d:c76+8 54M ess privacy rsn "DIRECT-bL-EPSON-XP-7100 Series"! Oct 14 08:23:41 x13 /bsd: iwx0: - 3c:a6:2f:b4:99:f51 +18 54M ess privacy rsn "MAESTRO"! Oct 14 08:23:41 x13 /bsd: iwx0: - 44:4e:6d:4f:c7:356 +12 54M ess privacy rsn "FRITZ!Box 6590 Cable MF"! Oct 14 08:23:41 x13 /bsd: iwx0: - 4c:1b:86:17:91:62 11 +21 54M ess privacy rsn "WLAN-791054"! Oct
Re: iwx(4) 40MHz channel support
joshua stein wrote: > On Thu, 14 Oct 2021 at 09:21:18 +0200, Stefan Hagen wrote: > > This ramp up time is reproducible. It always starts slower in the first > > 1 or 2 seconds and then ramps up to full speed. > > I've observed this in ethernet transfers on OpenBSD for a long time, > it's not limited to WiFi. > I see it, but only upstream. This is the upper link speed end for the iperf3 server (FreeBSD) as well, so the test may be skewed. Ethernet: [x13](0)(~)$ iperf3 -c 192.168.1.20 Connecting to host 192.168.1.20, port 5201 [ 5] local 192.168.1.69 port 37380 connected to 192.168.1.20 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 104 MBytes 876 Mbits/sec [ 5] 1.00-2.00 sec 104 MBytes 870 Mbits/sec [ 5] 2.00-3.00 sec 104 MBytes 870 Mbits/sec [ 5] 3.00-4.00 sec 104 MBytes 870 Mbits/sec [x13](1)(~)$ iperf3 -R -c 192.168.1.20 Connecting to host 192.168.1.20, port 5201 Reverse mode, remote host 192.168.1.20 is sending [ 5] local 192.168.1.69 port 44067 connected to 192.168.1.20 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 78.9 MBytes 662 Mbits/sec [ 5] 1.00-2.00 sec 110 MBytes 924 Mbits/sec [ 5] 2.00-3.00 sec 111 MBytes 929 Mbits/sec [ 5] 3.00-4.00 sec 110 MBytes 926 Mbits/sec Best regards, Stefan
Re: bsd.port.mk.5 typo
ha...@sdf.org wrote: > Index: bsd.port.mk.5 > === > RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v > retrieving revision 1.545 > diff -u -p -r1.545 bsd.port.mk.5 > --- bsd.port.mk.5 2 May 2021 06:13:57 - 1.545 > +++ bsd.port.mk.5 8 Oct 2021 00:02:30 - > @@ -3575,7 +3575,7 @@ Port uses > .Ev DEBUG_PACKAGES > so the > .Xr build-debug-info 1 > -script excepts debug information on all binaries and libraries. > +script expects debug information on all binaries and libraries. > Most probably, the build machinery for that specific port omitted -g > somewhere, or it runs strips during fake anyway. > It can also occur if commited with OK solene@ Thanks and best regards, Stefan
Add Apple heic/heif to magic(5) file
Hi, I'd like to add the mime magic for the Apple heic/heif formats, which are used by Apple devices in recent years to store media. This format family can contain still images, short sequences (live photos) and videos. The rules are taken from FreeBSD. OK? Best Regards, Stefan Index: usr.bin/file/magdir/animation === RCS file: /cvs/src/usr.bin/file/magdir/animation,v retrieving revision 1.6 diff -u -p -u -p -r1.6 animation --- usr.bin/file/magdir/animation 2 Jan 2016 13:25:33 - 1.6 +++ usr.bin/file/magdir/animation 25 Dec 2022 13:50:52 - @@ -65,6 +65,35 @@ !:mime video/mp4 >8 string/Wqt \b, Apple QuickTime movie !:mime video/quicktime +# HEIF image format +# see https://nokiatech.github.io/heif/technical.html +>8 string mif1\b, HEIF Image +!:mime image/heif +>8 string msf1\b, HEIF Image Sequence +!:mime image/heif-sequence +>8 string heic\b, HEIF Image HEVC Main or Main Still Picture Profile +!:mime image/heic +>8 string heix\b, HEIF Image HEVC Main 10 Profile +!:mime image/heic +>8 string hevc\b, HEIF Image Sequenz HEVC Main or Main Still Picture Profile +!:mime image/heic-sequence +>8 string hevx\b, HEIF Image Sequence HEVC Main 10 Profile +!:mime image/heic-sequence +# following HEIF brands are not mentioned in the heif technical info currently (Oct 2017) +# but used in the reference implementation: +# https://github.com/nokiatech/heif/blob/d5e9a21c8ba8df712bdf643021dd9f6518134776/Srcs/reader/hevcimagefilereader.cpp +>8 string heim\b, HEIF Image L-HEVC +!:mime image/heif +>8 string heis\b, HEIF Image L-HEVC +!:mime image/heif +>8 string avic\b, HEIF Image AVC +!:mime image/heif +>8 string hevm\b, HEIF Image Sequence L-HEVC +!:mime image/heif-sequence +>8 string hevs\b, HEIF Image Sequence L-HEVC +!:mime image/heif-sequence +>8 string avcs\b, HEIF Image Sequence AVC +!:mime image/heif-sequence >8 string CAEP\b, Canon Digital Camera >8 string caqv\b, Casio Digital Camera >8 string CDes\b, Convergent Design
Re: Support Wacom One M (CTL-672) [Was: Support Wacom One S (CTL-472)]
Sven M. Hallberg wrote (2022-12-08 14:12 CET):
> Marcus Glocker on Sat, Sep 03 2022:
> > I have an Wacom One CTL-672, never used it on OpenBSD.
>
> This is the "Wacom One M", which I also own...
>
> > Currently it attaches to ums(4). Works fine with that.
>
> It seems to expose two HIDs, one which reports as a regular "mouse" and
> makes it work like a touchpad (relative mode), and a second one (with a
> nonsense report descriptor) that can be used for absolute positioning.
>
> > It also works fine when attaching to uwacom(4), without and with your
> > diff. It doesn't seem to require specific 'tsscale' nor
> > 'loc_tip_press' settings.
>
> This does not match my experience; the second device (which uwacom
> attaches to) did not produce any events. It appears it needs the call to
> uhidev_set_report() of the "One S" code path to switch on.
>
> Trivial patch below that made it produce events for me.
>
> I did have to fiddle with xinput(1) to get the scale right. I ended up
> putting the following in its InputDevice section in /etc/X11/xorg.conf:
>
> Option "TransformationMatrix" "0.09 0 0 0 0.08 0 0 0 1"
>
> I wonder what the correct way is to avoid having to do this. Is it those
> tsscale parameters? If so, what's the best way to determine the correct
> values?
I don't think the scale values can be read from the device.
But you can get them from the linux wacom driver here:
https://github.com/linuxwacom/input-wacom/blob/master/4.5/wacom_wac.c#L11
Untested patch below.
Best Regards,
Stefan
diff --git a/sys/dev/usb/uwacom.c b/sys/dev/usb/uwacom.c
index f9af276a641..2c4e51b7522 100644
--- a/sys/dev/usb/uwacom.c
+++ b/sys/dev/usb/uwacom.c
@@ -149,6 +149,11 @@ uwacom_attach(struct device *parent, struct device *self,
void *aux)
ms->sc_tsscale.maxy = 9500;
}
+ if (uha->uaa->product == USB_PRODUCT_WACOM_ONE_M) {
+ ms->sc_tsscale.maxx = 21600;
+ ms->sc_tsscale.maxy = 13500;
+ }
+
if (uha->uaa->product == USB_PRODUCT_WACOM_INTUOS_DRAW) {
sc->sc_flags = UWACOM_USE_PRESSURE | UWACOM_BIG_ENDIAN;
sc->sc_loc_tip_press.pos = 43;
Re: [Patch] Probable error in sh.1
Ross L Richardson wrote (2022-12-18 10:55 CET): > The word "array" occurs only once in sh.1. Therefore, either it deserves > more explanation, or removal with something like the patch below. I think you're right. This looks like an oversight from the works when sh(1) was rewritten / split from ksh(1) in 2015. OK sdk@ > Ross > == > > --- sh.1.orig Thu Sep 1 10:07:22 2022 > +++ sh.1 Sun Dec 18 20:47:53 2022 > @@ -1390,7 +1390,7 @@ > .Pp > Where > .Ar expression > -is an integer, parameter name, or array reference, > +is an integer or parameter name, > optionally combined with any of the operators described below, > listed and grouped according to precedence: > .Bl -tag -width Ds >
Re: Please test: unlock mprotect/mmap/munmap
Martin Pieuchot wrote (2022-11-06 10:54 WET): > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > will reduce contention a lot. I'd be happy to hear from test reports > on many architectures and possible workloads. My two amd64 machines are happy with it for two days now. With several kernel builds and regular desktop use (browsers and such). Best Regards, Stefan
Re: AMD 17h/1xh HD Audio testers wanted!
Stefan Hagen wrote (2023-03-05 09:19 CET): > Alexandre Ratchov wrote (2023-03-05 08:53 CET): > > If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please > > test this diff and report regressions. Especially audio lock ups that > > require reboot. > > > > IIRC, MSI was disabled few years ago to "fix" such lockups, and now > > this diff suggests we need MSI on certain boards. > > At least no lockup in the first 5 minutes. I'll keep this in my tree. It took a few days, but I hit the bug now. No lockup, but audio simply stops and can not be reactivated until reboot. > OpenBSD 7.2-current (GENERIC.MP) #20: Sun Mar 5 09:10:14 CET 2023 > s...@x13.home.codevoid.de:/sys/arch/amd64/compile/GENERIC.MP > real mem = 16301219840 (15546MB) > avail mem = 15789305856 (15057MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf71 (68 entries) > bios0: vendor LENOVO version "R1CET73W(1.42 )" date 12/09/2022 > bios0: LENOVO 20UGS00800 > efi0 at bios0: UEFI 2.7 > efi0: Lenovo rev 0x1360 > acpi0 at bios0: ACPI 6.3 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT POAT BATB HPET APIC > MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT SSDT UEFI SSDT SSDT > acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) > GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu3: smt 1, core 1, package 0 > cp
Re: AMD 17h/1xh HD Audio testers wanted!
Alexandre Ratchov wrote (2023-03-05 08:53 CET): > If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please > test this diff and report regressions. Especially audio lock ups that > require reboot. > > IIRC, MSI was disabled few years ago to "fix" such lockups, and now > this diff suggests we need MSI on certain boards. At least no lockup in the first 5 minutes. I'll keep this in my tree. OpenBSD 7.2-current (GENERIC.MP) #20: Sun Mar 5 09:10:14 CET 2023 s...@x13.home.codevoid.de:/sys/arch/amd64/compile/GENERIC.MP real mem = 16301219840 (15546MB) avail mem = 15789305856 (15057MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf71 (68 entries) bios0: vendor LENOVO version "R1CET73W(1.42 )" date 12/09/2022 bios0: LENOVO 20UGS00800 efi0 at bios0: UEFI 2.7 efi0: Lenovo rev 0x1360 acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT POAT BATB HPET APIC MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT SSDT UEFI SSDT SSDT acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 cpu4:
Re: update: xf86-video-amdgpu 23.0.0
Matthieu Herrb wrote (2023-02-27 21:17 CET): > Hi, > > the patch below update the amdgpu(4) X.Org driver to version 23.0.0 > > To test (on machines with an AMD / Radeon GPU) > > # cd /usr/xenocara/driver/xf86-video-amdgpu > # patch -p0 -E < /path/to/this/file > # make -f Makefile.bsd-wrapper obj > # make -f Makefile.bsd-wrapper build > > and restart xenodm(1) > > Tests and oks welcome... Works fine for me. amdgpu0: RENOIR GC 9.3.0 7 CU rev 0x00 amdgpu0: 1920x1080, 32bpp ok sdk@
