[patch] unregister sr_sensors_refresh() after deleting last sensor

Hi, while playing around with softraid, I noticed that it lazily registers the sensor refresh task when the first volume is created, but it never removes it. The attached patch cleans it up when the last sensor is deleted. Having the one task linger around doing nothing every 10s is obviously

PATCH: xenocara/app/cwm: handle release of Meta (not Alt)

Hi, the attached patch solves an issue that I've had with cwm, namely that my Meta modifier would get stuck until I pressed some *other* modifier. The reason is that cwm's handling of modifier releases is rudimentary in that it just looks for key release events from any of a fixed list of keys

Support Wacom One M (CTL-672) [Was: Support Wacom One S (CTL-472)]

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

Re: Picky, but much more efficient arc4random_uniform!

Luke Small on Sun, May 15 2022: > The current implementation is nothing more than a naive arc4random() % > upper_bound which trashes initial arc4random() calls it doesn’t like, Yes, that's exactly what it is. > The whole transformation by modulus of perfectly decent random data > seems so

Re: slimblade support

Thomas Frohwein on Sat, Nov 21 2020: > Hi timo > > On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote: >> Hi, >> >> The last attempt at adding Kensington Slimblade trackball support seems >> to have stalled: >> https://marc.info/?l=openbsd-tech=147444999319756=2 > > Thanks for digging

Re: ksh tab completion bug

Apologies for jumping in as a bystander, but if I may comment: Anton Lindqvist on Tue, Nov 10 2020: > Been brought up before[1] and rejected[2][3]. Anton Lindqvist on Sun, Jul 02, 2017: > diff below in which slashes are discarded when comparing the length. I > don't know if any other character

Re: packets to bridged interfaces bypass input filter

Stephan Mending on Wed, May 27 2020: >> [bridge0 with members athn0 em0 vether0, all in group lan] >> >> # ifconfig athn0 -group lan > Did you flush states between your tests (pfctl -F states) ? -> After > you removed athn0 from lan group ? Yes, I did. >> [sys/net/if_bridge.c:

packets to bridged interfaces bypass input filter

hi all, i sent the following question to misc@ on march 29th but received no response. i hope you don't mind me retrying on tech@. while playing around with pf, i noticed that some connections that i thought should be blocked, were in fact not. here is my fairly standard bridge setup between a

Re: drm(4), multi-threaded task queues and barriers

Mark Kettenis on Thu, Jun 13 2019: > So here is a diff that fixes the problem as far as I can tell. > Jonathan, Sven, can you give this a go? Works for me. > + tq->tq_waiting++; > msleep(tq, >tq_mtx, PWAIT, "bored", 0); > + tq->tq_waiting--; Heh, didn't

Re: drm(4), multi-threaded task queues and barriers

Mark Kettenis on Wed, Jun 12 2019: >> Looks good and appears to work fine with two displays (one internal, one >> external). Will test with three at work tomorrow. Your diff also works for me with three displays (inteldrm). > Unfortunately the diff doesn't work with amdgpu. Some more thinking >

Re: drm(4), multi-threaded task queues and barriers

Mark Kettenis on Tue, Jun 11 2019: > The drm(4) codebase really needs multi-threaded task queues [...] > > The diff also starts 4 threads for each workqueue that gets created by > the drm(4) layer. The number 4 is a bit arbitrary but it is the > number of threads that Linux creates per CPU for a

inteldrm: cleanup_done timed out (ThinkPad X250)

Hi, Since updating my snapshot machine last night, I'm seeing the folloing. This is with one external monitor attached through the dock (DisplayPort). The "timed out" lines appear when X starts and halt it for a few minutes. Once X does come up, the error no longer appears. The last line ("FIFO

Re: patch: USB quirk to support extra buttons on Kensington Slimblade

Martin Pieuchot on Wed, Sep 21 2016: > Can you do that without adding a new quirk? Yes, but I guess then there would have to be a check for this particular product in the generic driver path? > Is this way of reporting extra buttons standard or is it a vendor-only > feature?

patch: USB quirk to support extra buttons on Kensington Slimblade

Ahoi OpenBSD, My trackball reports two out of its four buttons in a non-standard way. I've patched my kernel with a new USB quirk for this situation. [*] I'd like to contribute this if you want it; please let me know if this is the way to do it or if you'd like any changes. --pesco (sending