Currently the PiJuice HAT EEPROM doesn't ship with the Device Tree node
for the I2C MCU which delivers us the battery information. The reason
for that is most likely that Linux is offering a /dev/i2c device node
for userland programs, and the PiJuice team has developed an utility
which utilizes
On Fri, Oct 21, 2022 at 02:25:52PM +, Klemens Nanni wrote:
> Not that big, but quirks are likely to grow in the feature and there is
> no reason to keep them writable:
> 822c0750 g O .data 0160 uvideo_devs
>
> Builds fine on amd64 but I don't have uvideo(4) attaching
On Sat, Sep 03, 2022 at 05:43:25PM +0200, Caspar Schutijser wrote:
> Hi,
>
> On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> > This is a better version of an earlier attempt to make my wacom tablet
> > work. I have the tablet here in Bad Liebenzell if you want to give it a
> >
On Tue, Aug 30, 2022 at 07:17:19AM +0200, Marcus Glocker wrote:
> Periodic transfers on dwctwo(4) work very unreliable today. If I want
> to use my RPI3B+ as a workstation, the keyboard is working so
> unreliable, I can't hardly log-in to X. Playing USB audio isn't fun
> either
xhci(4) and ehci(4) are scheduling continuous isoc transfers. For that
we have implemented a kind of workaround, which checks whether
usbd_start_next() is calling in between and try to start an transfer
which is still in progress.
NetBSD has introduced a variable called 'serialise' for the pipe,
Left over from NetBSD code?
Index: sys/dev/fdt/bcm2835_mbox.c
===
RCS file: /cvs/src/sys/dev/fdt/bcm2835_mbox.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 bcm2835_mbox.c
--- sys/dev/fdt/bcm2835_mbox.c 6 Apr 2022 18:59:28
On Thu, Apr 14, 2022 at 10:00:35PM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Apr 2022 20:16:13 +0200
> > From: Marcus Glocker
> >
> > I did hit this panic when trying to stream audio through
> > uaudio(4) / dwctwo(4):
> >
> > panic:
I did hit this panic when trying to stream audio through
uaudio(4) / dwctwo(4):
panic: _dmamap_sync: ran off map!
Stopped at panic+0x160:cmp w21, #0x0
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*421282 69103 0 0x2
On Sun, Apr 10, 2022 at 03:28:41PM +0200, Christian Weisgerber wrote:
> Marcus Glocker:
>
> > > This constifies the bus method and pipe method tables in our USB
> > > host controller drivers.
> >
> > dwctwo(4) also exists on arm64.
>
> Oops, r
ci_device_ctrl_start,
> .abort = xhci_device_ctrl_abort,
> @@ -190,7 +190,7 @@ struct usbd_pipe_methods xhci_device_ctrl_methods = {
> .done = xhci_noop,
> };
>
> -struct usbd_pipe_methods xhci_device_intr_methods = {
> +const struct usbd_pipe_methods xhci_devi
When I understand it correctly, an utvfu(4) device supports either the
frame size for PAL or NTSC. So, the VIDIOC_ENUM_FRAMESIZES ioctl should
only return one frame size, which isn't the case currently. video(1)
repeatedly returns various times the same frame size, ffmpeg(1) and
ffplay(1) even
A friend of mine is trying to use two full HD cams on a OpenBSD laptop
to record his band sessions from two different angles. He can start
the first cam fine with 1920x1080, but if he tries to start the second
cam with 1920x1080 he runs out of USB memory.
That made me look in to the USB memory
In case you are playing around with isoc transfers (uvideo, uaudio) on
dwctwo(4), and you are facing kernel crashes, you can try this diff.
Or if you just want to regression test it. It basically does:
* Fix DMA allocation out of interrupt context.
* Fix a memory leak on DMA allocation during
On Sun, 8 Aug 2021 14:38:57 +1000
Jonathan Matthew wrote:
> While working on a new driver, I noticed we have a few places where we
> pass USBD_EXCLUSIVE_USE as the flags parameter to
> usbd_open_pipe_intr(), which is wrong.
>
> The interrupt pipe is always opened exclusively, and the flags
>
On Wed, 14 Jul 2021 11:53:50 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Mon, 12 Jul 2021 11:56:28 +1000
> > From: Jonathan Gray
> >
> > On Sun, Jul 11, 2021 at 05:55:14PM +0200, Marcus Glocker wrote:
> > > dwctwo(4) on the Raspberry Pi 3 has some issues toda
On Mon, 12 Jul 2021 11:56:28 +1000
Jonathan Gray wrote:
> On Sun, Jul 11, 2021 at 05:55:14PM +0200, Marcus Glocker wrote:
> > dwctwo(4) on the Raspberry Pi 3 has some issues today. Basically
> > uhub2 doesn't work which shows in:
> >
> > - mue(4) doe
On Wed, 14 Jul 2021 07:30:30 +0200
Martin Reindl wrote:
> On Sun, Jul 11, 2021 at 05:55:14PM +0200, Marcus Glocker wrote:
> >
> > Following the entire diff. And of course, general feedback and
> > comments? :-)
> >
>
> While I can't comment on the di
On Mon, 5 Apr 2021 23:54:31 +0200
Marcus Glocker wrote:
> On Mon, Apr 05, 2021 at 11:27:10PM +0200, Mark Kettenis wrote:
>
> [...]
>
> > > > > How common is it to explain the system behavior in cases like
> > > > > this? Would it be less surprising (ge
On Mon, Apr 05, 2021 at 11:27:10PM +0200, Mark Kettenis wrote:
[...]
> > > > How common is it to explain the system behavior in cases like this?
> > > > Would it be less surprising (generate less misc@ traffic) if we printed
> > > > a note explaining why the camera was skipped?
> > >
> > > I
On Mon, Apr 05, 2021 at 07:30:43AM -0700, Greg Steuck wrote:
> OK gnezdo with a usability question inline.
Thanks. See below.
> Marcus Glocker writes:
>
> > martijn@ has recently reported that in his machine he has two cams
> > of which one is doing IR, which i
Thanks for your feedback Matthias.
Unfortunately there wasn't too much acceptance for this diff from the
community, so it's unlikely that it will make it in to the tree.
Cheers,
Marcus
On Sat, 3 Apr 2021 10:25:58 +0200
Matthias Schmidt wrote:
> Hi,
>
> * Marcus Glocker wrote:
> &
me out :-)
>
> martijn@
>
> On Mon, 2021-03-15 at 08:35 +0100, Marcus Glocker wrote:
> > martijn@ has recently reported that in his machine he has two cams
> > of which one is doing IR, which isn't really supported by uvideo(4).
> > This IR device attaches always f
On Wed, Mar 24, 2021 at 09:23:22PM +0100, Mark Kettenis wrote:
> > Date: Wed, 24 Mar 2021 20:58:48 +0100
> > From: Marcus Glocker
> >
> > On Tue, Mar 23, 2021 at 09:52:42AM -0600, Theo de Raadt wrote:
> >
> > > Mark Kettenis wrote:
> > >
On Wed, Mar 24, 2021 at 02:05:27PM -0600, Theo de Raadt wrote:
> Marcus Glocker wrote:
>
> > On Tue, Mar 23, 2021 at 09:52:42AM -0600, Theo de Raadt wrote:
> >
> > > Mark Kettenis wrote:
> > >
> >
On Tue, Mar 23, 2021 at 09:52:42AM -0600, Theo de Raadt wrote:
> Mark Kettenis wrote:
>
> > > > Index: sys/dev/sdmmc/sdmmc_scsi.c
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v
> > > > retrieving revision 1.59
On Tue, Mar 23, 2021 at 08:29:06AM -0600, Theo de Raadt wrote:
> Marcus Glocker wrote:
>
> > Index: sys/dev/sdmmc/sdmmc_scsi.c
> > ===
> > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v
> > retrievin
I recently got a Raspberry Pi 3 Model B Plus (Rev 1.3). After
installing current the first thing during boot which I get is:
...
starting network
reordering libraries: done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
bcmsdhost0: transfer timeout!
martijn@ has recently reported that in his machine he has two cams
of which one is doing IR, which isn't really supported by uvideo(4).
This IR device attaches always first as uvideo0, so he needs to swap
that regularly with his working cam which by default attaches to uvideo1.
I came up with a
On Thu, Feb 25, 2021 at 10:36:02PM +0100, Marcus Glocker wrote:
> On Thu, Feb 25, 2021 at 09:14:06PM +, Stuart Henderson wrote:
>
> > On 2021/02/25 22:02, Marcus Glocker wrote:
> > > On Thu, Feb 25, 2021 at 08:00:32PM +, Stuart Henderson wrote:
> > >
>
On Thu, Feb 25, 2021 at 09:14:06PM +, Stuart Henderson wrote:
> On 2021/02/25 22:02, Marcus Glocker wrote:
> > On Thu, Feb 25, 2021 at 08:00:32PM +, Stuart Henderson wrote:
> >
> > > On 2021/02/25 20:10, Marcus Glocker wrote:
> > > > We had t
On Thu, Feb 25, 2021 at 08:00:32PM +, Stuart Henderson wrote:
> On 2021/02/25 20:10, Marcus Glocker wrote:
> > We had this discussion recently when fbtab(5) for xenodm(1) was fixed
> > 6 weeks ago, but we didn't come to an agreement yet. tb@ asked me the
> > same quest
On Thu, Feb 25, 2021 at 09:34:45PM +0100, Mark Kettenis wrote:
> > Date: Thu, 25 Feb 2021 20:10:00 +0100
> > From: Marcus Glocker
> >
> > We had this discussion recently when fbtab(5) for xenodm(1) was fixed
> > 6 weeks ago, but we didn't come to an agreement y
We had this discussion recently when fbtab(5) for xenodm(1) was fixed
6 weeks ago, but we didn't come to an agreement yet. tb@ asked me the
same question yesterday whether we can add video(1) to fbtab to avoid
manual chown of /dev/video0, which I think a lot of people do today.
Therefore here
On Sun, Feb 14, 2021 at 03:34:11PM +, Mikolaj Kucharski wrote:
> On Sun, Feb 14, 2021 at 03:22:28PM +0100, Marcus Glocker wrote:
> > Unfortunately I'm seeing more and more USB device breakages reported
> > the last few days related to the USB data toggle fix which we did
>
On Sun, Feb 14, 2021 at 04:43:17PM +, Stuart Henderson wrote:
> On 2021/02/14 15:22, Marcus Glocker wrote:
> > Unfortunately I'm seeing more and more USB device breakages reported
> > the last few days related to the USB data toggle fix which we did
> > commit 2-3 weeks a
Unfortunately I'm seeing more and more USB device breakages reported
the last few days related to the USB data toggle fix which we did
commit 2-3 weeks ago.
Since I can't reproduce the issue here with my USB gear, it's very
difficult for me to pin point the issue. Therefore I think we should
On Sat, Feb 13, 2021 at 10:45:17AM +0100, Claudio Jeker wrote:
> On Sat, Feb 13, 2021 at 10:26:48AM +0100, Marcus Glocker wrote:
> > On Sat, Feb 13, 2021 at 08:30:04AM +0100, Claudio Jeker wrote:
> >
> > > On Fri, Feb 12, 2021 at 10:59:05PM +0100, Jeremie Courreges-Angl
On Sat, Feb 13, 2021 at 08:30:04AM +0100, Claudio Jeker wrote:
> On Fri, Feb 12, 2021 at 10:59:05PM +0100, Jeremie Courreges-Anglas wrote:
> > On Wed, Feb 10 2021, Martin Pieuchot wrote:
> >
> > [...]
> >
> > > Which fields is the new lock protecting? Why isn't the KERNEL_LOCK()
> > > enough?
My boot.conf was renamed to boot.conf.off in the PXE server. Idiot.
Thanks tb@ for the hint :-)
Sorry for the noise.
On Thu, Feb 11, 2021 at 04:07:02PM +0100, Marcus Glocker wrote:
> Is there anyone out there using an apu2e4?
>
> I just received an APU2E4 / GX-412TC 4GB
&
Is there anyone out there using an apu2e4?
I just received an APU2E4 / GX-412TC 4GB
https://www.pcengines.ch/apu2e4.htm
I can't boot any recent kernel on it, not through USB nor through
PXEBOOT. I tried amd64/i386, snapshot, 6.8, 6.6, and all cause the apu
to reboot after the entry point
jca@ has recently committed a change to video(4) to allow the same
process to do multiple opens on the same video device to satisfy
certain applications, and start to go in to the V4L2 "1.1.4 Multiple
Opens" specification direction as described here:
On Thu, Feb 04, 2021 at 10:28:42PM +0100, Thomas Jeunet wrote:
> On Wed, Feb 03, 2021 at 08:30:42PM +0100, Marcus Glocker wrote:
> > On Sun, Jan 31, 2021 at 07:05:29PM +0100, Thomas Jeunet wrote:
> >
> > > Hello tech,
> > >
> > > in ugen_set_config
On Fri, Jan 29, 2021 at 08:16:27AM +0100, Anton Lindqvist wrote:
> Hi,
> While running usbhidctl on my USB mouse it occasionally fails as
> follows:
>
> # usbhidctl -f /dev/wsmouse2
> usbhidctl: USB_GET_REPORT (probably not supported by device): Bad
> address
>
> The EFAULT
On Sun, Jan 31, 2021 at 07:05:29PM +0100, Thomas Jeunet wrote:
> Hello tech,
>
> in ugen_set_config, the cached config descriptor (ugen.c:213) is
> obsolete after the call to usbd_set_config_no (ugen.c:220). Use a
> refreshed value so the next loop account for the correct number of
> interfaces.
On Tue, Feb 02, 2021 at 07:55:17PM +0100, Anton Lindqvist wrote:
[...]
> > > However, it would ease development by getting this in and continue
> > > development in tree. Anyone willing to ok?
> >
> > The reason why I'm currently reluctant to ok this is because of the
> > uhidev_set_intr() part
On Tue, Feb 02, 2021 at 08:23:29AM +0100, Anton Lindqvist wrote:
> On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote:
> > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote:
> > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote:
> > > > Hi,
> > > >
> > > > I
On Thu, Jan 28, 2021 at 02:38:04PM +, Edd Barrett wrote:
> On Thu, Jan 28, 2021 at 09:56:14AM +, Edd Barrett wrote:
> >
>
> Here's a revised diff that always searches the array, instead of first
> trying the expected index. Everyone agreed that this makes for simpler
> code, and that
On Tue, Jan 26, 2021 at 08:56:29PM +, Edd Barrett wrote:
> Hi,
>
> I've recently come across a uaudio device which doesn't work in OpenBSD:
>
> uaudio2 at uhub0 port 1 configuration 1 interface 3 "E+ Corp. DAC Audio" rev
> 1.10/0.01 addr 2
> uaudio2: class v1, full-speed, async, channels:
On Fri, Jan 22, 2021 at 01:52:24PM -0700, Thomas Frohwein wrote:
> On Fri, Jan 22, 2021 at 02:26:31PM -0500, Bryan Steele wrote:
> > On Fri, Jan 22, 2021 at 07:00:57PM +0100, Marcus Glocker wrote:
>
> [...]
>
> > > > > Considering the hid_is_coll
On Fri, 15 Jan 2021 22:41:13 +0100
Marcus Glocker wrote:
> On Fri, 15 Jan 2021 11:37:47 -0500
> Bryan Steele wrote:
>
> > On Fri, Jan 15, 2021 at 06:23:01AM -0700, Thomas Frohwein wrote:
> > > On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
> &
On Wed, 20 Jan 2021 21:42:21 -0600
joshua stein wrote:
> There are no i2c-connected mice and ims(4) will always be a
> touchpad/touchscreen/stylus that just doesn't meet the requirements
> of imt(4).
>
> Presenting it as WSMOUSE_TYPE_TOUCHPAD makes the X server set it up
> as a separate
Thanks for testing this Greg.
On Sat, 16 Jan 2021 16:10:26 -0800
Greg Steuck wrote:
> Hi Marcus,
>
> Marcus Glocker writes:
>
> > There are a few threads going on related to problems with ugen(4)
> > and uhidev(4) devices on xhci(4). This is related to the is
On Fri, 15 Jan 2021 11:37:47 -0500
Bryan Steele wrote:
> On Fri, Jan 15, 2021 at 06:23:01AM -0700, Thomas Frohwein wrote:
> > On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
> > > On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote:
> > >
On Fri, 15 Jan 2021 06:23:01 -0700
Thomas Frohwein wrote:
> On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
> > On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote:
> >
> > > > I have heard from others who tried the diff that the PS4
&g
There are a few threads going on related to problems with ugen(4) and
uhidev(4) devices on xhci(4). This is related to the issue patrick@
already explained; while ehci(4) can save the last data toggle state,
xhci(4) resets it on every open/close cycle, getting out of sync with
the device.
This
On Sun, 10 Jan 2021 00:04:21 +0100
Marcus Glocker wrote:
> On Sat, 9 Jan 2021 21:51:03 +0100 (CET)
> Mark Kettenis wrote:
>
> > > Date: Sat, 9 Jan 2021 10:38:20 +0100
> > > From: Marcus Glocker
> > >
> > > I have not much clue about HID, but when
On Sat, 09 Jan 2021 14:39:53 -0800
Greg Steuck wrote:
> Thanks for the reviews!
>
> Marcus Glocker writes:
>
> > On Sat, 9 Jan 2021 22:09:06 +0100
> > Marcus Glocker wrote:
> > If you could fix the switch() indentation in a separate commit (as
> >
On Sat, 9 Jan 2021 21:51:03 +0100 (CET)
Mark Kettenis wrote:
> > Date: Sat, 9 Jan 2021 10:38:20 +0100
> > From: Marcus Glocker
> >
> > I have not much clue about HID, but when we did some testing for the
> > new ujoy(4) driver it turned out that the PS4 cont
On Sat, 9 Jan 2021 22:09:06 +0100
Marcus Glocker wrote:
> On Sat, 09 Jan 2021 13:06:36 -0800
> Greg Steuck wrote:
>
> > Thanks Todd for reviewing these boring patches!
> >
> > Todd C. Miller writes:
> >
> > > Updated diff looks good to me. OK
On Sat, 09 Jan 2021 13:06:36 -0800
Greg Steuck wrote:
> Thanks Todd for reviewing these boring patches!
>
> Todd C. Miller writes:
>
> > Updated diff looks good to me. OK millert@ but it would be good
> > to get feedback from Marcus too.
>
> Sure thing, I'll wait till tomorrow then?
>
>
I have not much clue about HID, but when we did some testing for the
new ujoy(4) driver it turned out that the PS4 controller doesn't get
handled correctly by hid.c:hid_is_collection(). This made me peek in
to the NetBSD code where I could find an update in this function.
Syncing it up makes the
On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote:
> > I have heard from others who tried the diff that the PS4 controller is
> > causing problems with the way it attaches. I ordered one to trial-and-
> > error this myself at home. Could you share output of
On Thu, 7 Jan 2021 10:20:34 -0700
Thomas Frohwein wrote:
> On Wed, Jan 06, 2021 at 10:48:58PM +0100, Marcus Glocker wrote:
>
> [...]
>
> > The implementation as such looks fine to me.
> > But I quickly gave the diff a spin before on amd64 using my PS
> > controll
On Mon, Dec 28, 2020 at 05:03:14PM -0700, Thomas Frohwein wrote:
> Hi,
>
> This is a diff to propose a new device type for USB gamecontrollers,
> 'ujoy'.
>
> Rationale
> -
>
> Since the tightening of security around USB devices, USB
> gamecontrollers that generally attach to the
On Tue, Jan 05, 2021 at 11:54:31PM +0100, Jeremie Courreges-Anglas wrote:
>
> I hit a weird failure with firefox and BigBlueButton
> (https://bigbluebutton.org/) where firefox can't use my webcam.
> video(1) works, same for other webrtc sites in firefox, eg meet.jit.si.
> ktrace shows that a
On Tue, Dec 29, 2020 at 11:09:44PM +0100, Mark Kettenis wrote:
> > Date: Tue, 29 Dec 2020 15:24:58 +0100
> > From: Marcus Glocker
> >
> > Now that we have a switch in place with kern.video.record which requires
> > initial root access to enable video reco
Now that we have a switch in place with kern.video.record which requires
initial root access to enable video recording, I want propose the idea
of making the /dev/video* devices accessible to users who are a member
of the 'video' group:
lrwxr-xr-x 1 root wheel 6 Dec 29 12:38
On Tue, 29 Dec 2020 14:40:09 +0100
Sebastian Benoit wrote:
> ok.
>
> maybe add a line to current.html so that people are not surprised
> that their video is no longer working after upgrade.
Looks like sthen@ was already there :-)
> /Benno
>
>
> Marcus Glocker(mar...@
/video*. By that we require initial root access to enable
video recording, but can then permit non-root accounts for video
access.
On Wed, 16 Dec 2020 15:57:20 +
Laurence Tratt wrote:
> On Wed, Dec 16, 2020 at 03:50:54PM +0100, Marcus Glocker wrote:
>
> Hello Marcus,
>
&g
On Wed, 23 Dec 2020 17:35:36 +0100
Patrick Wildt wrote:
> Am Wed, Dec 23, 2020 at 10:44:21AM +0100 schrieb Marcus Glocker:
> > On Wed, 23 Dec 2020 09:47:44 +0100
> > Marcus Glocker wrote:
> >
> > > On Tue, 22 Dec 2020 20:55:41 +0100
> > > Marcus Glock
On Wed, 23 Dec 2020 09:47:44 +0100
Marcus Glocker wrote:
> On Tue, 22 Dec 2020 20:55:41 +0100
> Marcus Glocker wrote:
>
> > > > Did you consider incrementing xx->ntrb instead?
> >
> > >That doesn't work either, because the status completion
On Tue, 22 Dec 2020 20:55:41 +0100
Marcus Glocker wrote:
> > > Did you consider incrementing xx->ntrb instead?
>
> >That doesn't work either, because the status completion code needs
> >xx->ntrb to be correct for the data TD to be handled correctly.
> >In
> > Did you consider incrementing xx->ntrb instead?
>That doesn't work either, because the status completion code needs
>xx->ntrb to be correct for the data TD to be handled correctly.
>Incrementing xx->ntrb means the number of TRBs for the data TD is
>incorrect, since it includes the (optional)
Hi,
In September Laurence Tratt came up with a diff to implement an
kern.video.record switch for sysctl(8). The implementation was only
for uvideo(4), and hence we wanted to lift that up to the video(4)
level, but we were not able to get a good implementation together back
then.
I reviewed this
On Fri, Dec 11, 2020 at 10:01:35AM +0100, Alexandre Ratchov wrote:
> On Fri, Dec 11, 2020 at 09:07:45AM +0100, Marcus Glocker wrote:
> >
> > After doing some deeper analyzes in to asmc_wait() I agree to that.
> > Something seems to go fundamental wrong there.
On Thu, Dec 10, 2020 at 06:06:26PM -0300, Martin Pieuchot wrote:
> On 10/12/20(Thu) 21:40, Alexandre Ratchov wrote:
> > On Thu, Dec 10, 2020 at 05:27:16PM +0100, Marcus Glocker wrote:
> > > Hi All,
> > >
> > > I recently started to play around with uvideo(4) a
Hi All,
I recently started to play around with uvideo(4) and uaudio(4) on my
amd64 iMacs. There I quickly noticed regular freezes when streaming
USB video or audio. On some of those machines it was very frequent,
like every few seconds the video or audio stream did freeze for ~1s,
then resume,
would actually
> offer in any way (as most of today's laptops -- including Apple
> MacBook macOS ones -- are completely unusable on the lap due to the
> terrible thermal profiles and a seeming lack of temperature-based
> control options for their active cooling components).
>
> Chee
sofs/cd9660/cd9660_node.ccd9660
Index: sys/dev/fan.c
===
RCS file: sys/dev/fan.c
diff -N sys/dev/fan.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/dev/fan.c 27 Nov 2020 16:13:54 -
@@ -0,0 +1,229 @@
+/* $OpenBSD$ */
+
+/*
+
On Sat, Oct 24, 2020 at 01:17:05PM -0600, Theo de Raadt wrote:
> Seems better.
>
> Toggling the behaviour while video occurs should be tested, to make
> sure it matches expectations.
Right, works already for read(2) but for mmap(2) we need to move the
check to the VIDIOC_DQBUF ioctl(2) then.
I
On Sat, Oct 24, 2020 at 11:34:07AM -0600, Theo de Raadt wrote:
> Marcus Glocker wrote:
>
> > On Sun, Sep 27, 2020 at 05:57:51PM +0100, Laurence Tratt wrote:
> >
> > > On Sun, Sep 13, 2020 at 09:23:36AM +0100, Laurence Tratt wrote:
> > >
> > &g
On Sun, Sep 27, 2020 at 05:57:51PM +0100, Laurence Tratt wrote:
> On Sun, Sep 13, 2020 at 09:23:36AM +0100, Laurence Tratt wrote:
>
> > Since I recently opened my big fat mouth and suggested that
> > "kern.video.record" (analogous to kern.audio.record) might be a good idea, I
> > decided to put
On Sat, 17 Oct 2020 14:26:49 +0100
Raf Czlonka wrote:
> Ping.
It's committed, thanks.
> On Sun, Oct 11, 2020 at 11:33:21AM BST, Raf Czlonka wrote:
> > Hi all,
> >
> > I just dug a Logitech Webcam Pro 9000 (for Business) out.
> >
> > After a quick test, it seems to be working just fine but
On Sat, 12 Sep 2020 10:28:23 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Sat, 12 Sep 2020 10:00:13 +0200
> > From: Marcus Glocker
> >
> > On Sat, 12 Sep 2020 09:34:18 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > > Date: Sat, 12 Sep
On Sat, 12 Sep 2020 09:34:18 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Sat, 12 Sep 2020 09:20:26 +0200
> > From: Marcus Glocker
> >
> > On Fri, 11 Sep 2020 23:18:56 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > > Date: Fri, 11 Sep
On Fri, 11 Sep 2020 23:18:56 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Fri, 11 Sep 2020 17:42:23 +0200
> > From: Marcus Glocker
> >
> > On Thu, 10 Sep 2020 23:44:38 +0200
> > Joerg Jung wrote:
> >
> > > Don’t give up so quickly ;)
> &g
On Thu, 10 Sep 2020 23:44:38 +0200
Joerg Jung wrote:
> Don’t give up so quickly ;)
> let’s try to make the driver work on your iMac, send me dmesg and
> sysctl hw output please.
>
> Your idea of converting it to ACPI is the right thing to do anyways,
> would be nice to get this working.
Here
On Thu, 10 Sep 2020 23:07:15 +0200
Joerg Jung wrote:
> > Am 07.09.2020 um 20:52 schrieb Mark Kettenis
> > :
> >> Date: Mon, 7 Sep 2020 19:59:13 +0200
> >> From: Marcus Glocker
> >> On Mon, 7 Sep 2020 19:25:00 +0200 (CEST)
> >> Mark Kettenis
On Mon, 7 Sep 2020 21:39:55 +0200
Marcus Glocker wrote:
> On Mon, 7 Sep 2020 20:50:20 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > Date: Mon, 7 Sep 2020 19:59:13 +0200
> > > From: Marcus Glocker
> > >
> > > On Mon, 7 Sep 2020 19:
On Mon, 7 Sep 2020 20:50:20 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Mon, 7 Sep 2020 19:59:13 +0200
> > From: Marcus Glocker
> >
> > On Mon, 7 Sep 2020 19:25:00 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > > Date: Mon, 7 Se
On Mon, 7 Sep 2020 19:25:00 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Mon, 7 Sep 2020 12:02:15 -0500
> > From: joshua stein
> >
> > On Mon, 07 Sep 2020 at 06:58:01 +0200, Marcus Glocker wrote:
> > > This is an initial driver for the Apple System Managemen
Sep 2020 04:54:57 -
@@ -0,0 +1,63 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2020 Marcus Glocker
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that t
Since we can't always rely on wTotalLength to be correct, use the
variable which has been used to malloc(9) cdesc to free(9) it again,
instead of freeing wTotalLength. usbd_get_cdesc() already has the
feature built-in to return the length it has used to malloc(9) cdesc.
OK?
Index: ugen.c
On Sun, 23 Aug 2020 08:59:10 +0100
Laurence Tratt wrote:
> On Sun, Aug 23, 2020 at 09:17:57AM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> > Sorry for the delay - I'm back to business mode and need to take
> > care about naive project managers with cra
wrote:
> On Sat, Aug 08, 2020 at 11:29:41PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> >>>> One other thing has occurred to me -- but can be done in a
> >>>> future patch -- is that we probably want to be able to do:
> >>>>
>
On Sat, 22 Aug 2020 14:09:53 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Mon, 17 Aug 2020 12:57:58 +0200 (CEST)
> > From: Mark Kettenis
> >
> > > Date: Sun, 16 Aug 2020 19:32:03 +0200 (CEST)
> > > From: Mark Kettenis
> > >
> > > The diff below adds support for higher speeds as supported by
Is ubcmtp(4) really attaching to uhidev(4)? I only can see it
attaching to uhub(4). Do I miss something?
Index: sys/dev/usb/ubcmtp.c
===
RCS file: /cvs/src/sys/dev/usb/ubcmtp.c,v
retrieving revision 1.21
diff -u -p -u -p -r1.21
Hi,
Recently I took over the old iMac11,2 of my son, and what else to do
with it other than installing OpenBSD and see what happens. The first
thing which happened after the installation was that the screen
remained dark after the radeondrm(4) KMS initialization.
After some painful debugging,
Hello Laurie,
On Sat, 8 Aug 2020 21:56:08 +0100
Laurence Tratt wrote:
> On Sat, Aug 08, 2020 at 09:30:18PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> >> I like your patch, which is better than my original! My only very
> >> minor comment is whether we mi
On Sat, 08 Aug 2020 17:08:01 +0200
sxv...@firemail.cc wrote:
> So I recently installed OpenBSD on an EeePC 900HD with an Elantech v1
> touchpad (fw_version 0x20022).
> This specific fw version for some reason sends inverted parity bits
> on a cold boot, returning to normal after suspend & resume.
1 - 100 of 204 matches
Mail list logo
