The HID code uses hid_feature, hid_input, and hid_output constants
to refer to report types internally that then need to be converted
to their bus-level counterparts before actually getting sent out (so
hid_feature becomes UHID_FEATURE_REPORT for USB,
I2C_HID_REPORT_TYPE_FEATURE for i2c).
On Sat, Aug 25, 2018 at 07:53:55AM +0900, YASUOKA Masahiko wrote:
> On Fri, 24 Aug 2018 10:55:52 +0200
> Patrick Wildt wrote:
> > On Fri, Aug 24, 2018 at 10:47:27AM +0200, Theo Buehler wrote:
> >> On Fri, Aug 24, 2018 at 11:50:51AM +0900, YASUOKA Masahiko wrote:
> >> > Hi,
> >> >
> >> > I think
On Fri, 24 Aug 2018 10:55:52 +0200
Patrick Wildt wrote:
> On Fri, Aug 24, 2018 at 10:47:27AM +0200, Theo Buehler wrote:
>> On Fri, Aug 24, 2018 at 11:50:51AM +0900, YASUOKA Masahiko wrote:
>> > Hi,
>> >
>> > I think the diff should be brought to arm64 as well. ok?
>>
>> ok. But shouldn't armv7
ACPI devices typically have two methods that identify the device.
_HID returns a "hardware ID" and _CID returns a "compatible ID". The
idea is that _HID return an ID for the specific hardware. But if the
device is compatible with a more generic implementation, _CID can be
used to indicate that
On Tue, Aug 21, 2018 at 08:07:03PM +0200, Mark Kettenis wrote:
> > Date: Mon, 20 Aug 2018 20:55:16 +0200 (CEST)
> > From: Mark Kettenis
> >
> > > Date: Mon, 20 Aug 2018 15:46:57 +0200
> > > From: Frederic Cambus
> > >
> > > There is an issue when moving the cursor backwards with the left arrow
Scott Cheloha wrote:
> On Fri, Aug 24, 2018 at 10:21:08AM -0600, Theo de Raadt wrote:
> > Scott Cheloha wrote:
> >
> > > [...]
> > >
> > > I'm hunting this code because it mentions "no sysctl" as its raison
> > > d'etre, which is definitely not a reason for keeping it.
> >
> > It is
On Fri, Aug 24, 2018 at 10:21:08AM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > [...]
> >
> > I'm hunting this code because it mentions "no sysctl" as its raison
> > d'etre, which is definitely not a reason for keeping it.
>
> It is confusing that it says sysctl (rather than
Scott Cheloha wrote:
> I mean, if there are nasty situations where you're trying to bring
> up a fubar'd box where getting init to exec the single-user shell
> makes or breaks your efforts, then I can just update the comment to
> indicate this.
>
> Do such situations occur anymore (anyone
On Fri, Aug 24, 2018 at 10:02:21AM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > The badsys() function has been here since import. Its comment
> > indicates that SIGSYS might arrive if the system doesn't support
> > sysctl, which is not applicable to us anymore, if ever.
> >
> > The
Scott Cheloha wrote:
> The badsys() function has been here since import. Its comment
> indicates that SIGSYS might arrive if the system doesn't support
> sysctl, which is not applicable to us anymore, if ever.
>
> The only legitimate case I can think of here, now, is the desire
> to support
The badsys() function has been here since import. Its comment
indicates that SIGSYS might arrive if the system doesn't support
sysctl, which is not applicable to us anymore, if ever.
The only legitimate case I can think of here, now, is the desire
to support dropping an old init(8) onto a new
On Fri, Aug 24, 2018 at 11:57:54AM +0100, Ricardo Mestre wrote:
> Hi,
>
> Similar to the patch I just sent for smsc(4) this one also has a misplaced
> parenthesis in an if-clause. NetBSD fixed this on rev 1.13.
>
> OK?
OK claudio
> Index: if_upgt.c
>
On Wed, Aug 22 2018, Scott Cheloha wrote:
> Check for failure.
>
> Also reuse retval for the buffer length in lieu of strlen.
>
> ok?
Glancing at SSL_write(3), shouldn't this code loop if we get an error
and SSL_get_error(3) returns SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE? Or perhaps it
Hi,
it’s not like that, maybe I wasn’t clear. Let me try to explain:
- you can boot from disk (-d)
- you can boot an OpenBSD kernel or use a custom BIOS (-b)
- you can boot from CDROM (-r)
vmd/vmctl checks if at least one option is available.
If you specify neither of these options, you can
I think it should since it might return != 0, but what exactly should be
done in this case? I don't have such hardware to test those conditions
and if it keeps working anyway or not if it happens.
On 13:25 Fri 24 Aug , Jeremie Courreges-Anglas wrote:
> On Fri, Aug 24 2018, Ricardo Mestre
On Fri, Aug 24 2018, Ricardo Mestre wrote:
> Hi,
>
> Similar to the patch I just sent for smsc(4) this one also has a misplaced
> parenthesis in an if-clause. NetBSD fixed this on rev 1.13.
>
> OK?
ok jca@
> Index: if_upgt.c
> ===
On Fri, Aug 24 2018, Edd Barrett wrote:
> On Fri, Aug 24, 2018 at 11:47:35AM +0200, Mark Kettenis wrote:
>> correct, but I'd leave out the second "until".
>
> I prefer with the second until, but I'm not super-fussed.
>
> Here's the diff without the second, OK?
ok jca@
> Index: dl_iterate_phdr.3
On Fri, Aug 24 2018, Ricardo Mestre wrote:
> Hi,
>
> smsc(4) needs a fix to an assignment which I found with cppcheck. FreeBSD also
> made this change 2 years ago on rev 295608.
>
> OK?
This diff shouldn't change the semantics but it looks saner this way
indeed. ok jca@
The return value of
On Fri, Aug 24, 2018 at 11:57:54AM +0100, Ricardo Mestre wrote:
> Hi,
>
> Similar to the patch I just sent for smsc(4) this one also has a misplaced
> parenthesis in an if-clause. NetBSD fixed this on rev 1.13.
>
> OK?
ok
> Index: if_upgt.c
>
Hi,
Similar to the patch I just sent for smsc(4) this one also has a misplaced
parenthesis in an if-clause. NetBSD fixed this on rev 1.13.
OK?
Index: if_upgt.c
===
RCS file: /cvs/src/sys/dev/usb/if_upgt.c,v
retrieving revision 1.81
Hi,
smsc(4) needs a fix to an assignment which I found with cppcheck. FreeBSD also
made this change 2 years ago on rev 295608.
OK?
Index: if_smsc.c
===
RCS file: /cvs/src/sys/dev/usb/if_smsc.c,v
retrieving revision 1.31
diff -u -p
On Fri, Aug 24, 2018 at 08:58:12AM +0200, Claudio Jeker wrote:
> On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote:
> > On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> > > On 2018/08/21 17:16, Remi Locherer wrote:
> > > > Hi tech,
> > > >
> > > > recently we had a
On Fri, Aug 24, 2018 at 11:47:35AM +0200, Mark Kettenis wrote:
> correct, but I'd leave out the second "until".
I prefer with the second until, but I'm not super-fussed.
Here's the diff without the second, OK?
Index: dl_iterate_phdr.3
> Date: Fri, 24 Aug 2018 10:20:19 +0100
> From: Edd Barrett
>
> Hi,
>
> I've been working with dl_iterate_phdr(3) recently, and noticed a
> missing detail from our manual page: when the callback returns non-zero,
> iteration stops. This is documented in the Linux manual page, and I've
> also
Hi,
I've been working with dl_iterate_phdr(3) recently, and noticed a
missing detail from our manual page: when the callback returns non-zero,
iteration stops. This is documented in the Linux manual page, and I've
also verified this behaviour in our code:
dlfcn.c:
---8<---
for (object =
On Fri, Aug 24, 2018 at 10:47:27AM +0200, Theo Buehler wrote:
> On Fri, Aug 24, 2018 at 11:50:51AM +0900, YASUOKA Masahiko wrote:
> > Hi,
> >
> > I think the diff should be brought to arm64 as well. ok?
>
> ok. But shouldn't armv7 also be kept in sync?
Exactly.
>
> >
> > On Thu, 23 Aug 2018
On Tue, 21 Aug 2018 23:03:36 -0700, Carlos Cardenas
wrote:
> On Sun, Aug 19, 2018 at 11:46:12PM -0700, Ori Bernstein wrote:
> > One more minor update to this patch:
> >
> > - Remove unused enum
> > - Remove unused function prototype
> > - Move some qcow2-specific headers into the
On Fri, Aug 24, 2018 at 11:50:51AM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> I think the diff should be brought to arm64 as well. ok?
ok. But shouldn't armv7 also be kept in sync?
>
> On Thu, 23 Aug 2018 11:21:57 +0900 (JST)
> YASUOKA Masahiko wrote:
> > On Mon, 20 Aug 2018 13:50:13 +0200
> >
On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote:
> On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> > On 2018/08/21 17:16, Remi Locherer wrote:
> > > Hi tech,
> > >
> > > recently we had a short outage in our network. A script started an
> > > additional
> > >
On Thu, Aug 23, 2018 at 08:16:06AM +0200, Anton Lindqvist wrote:
> Hi.
> Currently kcov is enabled on a per process (pid) basis. A process with
> multiple threads therefore share the same coverage buffer which leads to
> non-deterministic results. Instead, kcov should be enabled on a per
> thread
30 matches
Mail list logo
