Hello OpenBSD developers,
I am interested in contributing to improve the uhidpp(4)
(Logitech Unifying Reciever) support in OpenBSD.
Currently, the uhidpp(4) driver only handles detecting certain
sensors, but I would like more robust support for these devices,
including:
* pairing and unpairing
This diff switches internal sample representation frem 16-bit to
24-bit fixed-point. Resampling is already 24-bit only, so there's
little point in keeping the current 16-bit code.
The default device precision doesn't change, i.e. we still request the
same 16-bit mode (and convert everything to 24-
On Tue, Dec 21, 2021 at 07:00:03PM +0100, Claudio Jeker wrote:
> For some reasons various ids were stored as size_t (probably because once
> they used to be the index in an array). This is just silly and annoyed me
> for long enough. I think this fixes all of them.
>
> While there also stop using
In the roa parser the handling of maxlen is overly complex.
Just set maxlen to addr.prefixlen before parsing the maxlength option.
If present it will override maxlen with the new value and with that the
ternary confusion at the end can be removed.
--
:wq Claudio
Index: roa.c
For some reasons various ids were stored as size_t (probably because once
they used to be the index in an array). This is just silly and annoyed me
for long enough. I think this fixes all of them.
While there also stop using size_t for maxlength of a prefix. Everywhere
else the code uses just a un
The limiter for repository count under a TA only makes sense for
repositories referenced from certs but less so for the actual TA. So
remove the logic from ta_lookup() and friends and make the code simpler.
There is no risk in doing so since there is only one TA and one
ta_lookup() done per TAL and
Hi,
I would like to use TAILQ_FOREACH to traverse the disk list.
Code is easier to read.
ok?
bluhm
Index: kern/kern_sysctl.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.396
diff -u -p -
On Tue, Dec 21, 2021 at 09:43:27AM +0100, Ingo Schwarze wrote:
> Jason McIntyre wrote on Mon, Dec 20, 2021 at 04:13:19PM +:
>
> > i'm ok with your diff
>
> Thanks for checking.
>
> > but it is slightly misleading in context of
> > reading from stdin. i suppose that is no biggie.
>
> I think
Hi Theo,
Theo de Raadt wrote on Mon, Dec 20, 2021 at 10:37:00AM -0700:
> Ingo Schwarze wrote:
>> The patch(1) manual talks about "lines" throughout,
>> and for binary files, a concept of "lines" does not even exist.
> That is a bit strong. Some utilities designed for "text files" have no
> pro
Jason McIntyre wrote on Mon, Dec 20, 2021 at 04:13:19PM +:
> i'm ok with your diff
Thanks for checking.
> but it is slightly misleading in context of
> reading from stdin. i suppose that is no biggie.
I think i see why you say so.
Speaking *formally*, what we usually do is describing what
10 matches
Mail list logo