On Sat, Nov 26, 2022 at 1:47 AM Anton Lindqvist wrote:
> Hi,
> This diff adds supports for the following to uhidpp:
>
> 1. Bolt receivers, they use a different set of registers for querying
>paired devices.
>
> 2. The Unified Battery feature, this is a more competent feature
>function use
On Thu, Jul 15, 2021 at 11:20 AM Leo Unglaub wrote:
> Hey,
> this is a very clean solution to a very common problem that i have. A
> lot of tasks that i run from cron have very different completion times.
> Right now i use the -s [1] option in crontab to make sure only one task
> is running at on
On Mon, Oct 26, 2020 at 3:18 PM Mark Kettenis
wrote:
> > Date: Sun, 25 Oct 2020 10:42:38 +0100 (CET)
> > From: Mark Kettenis
> >
> > While making radeondrm(4) work on powerpc64 I'm running into an
> > interesting unaligned access issue.
> >
> > Modern POWER CPUs generally support unaligned acces
On Mon, Aug 31, 2020 at 2:41 AM Otto Moerbeek wrote:
> Hi,
>
> A question from Theo made me think about realloc and come up with a
> particular bad case for performance. I do not know if it happens in
> practice, but it was easy to create a test program to hit the case.
>
> We're talking allocati
On Fri, Jun 12, 2020 at 9:41 AM Theo Buehler wrote:
> I finally found the time to think about the mathematics of this some
> more and I'm now convinced that it's a sound construction. I hope that
> one or the other observation below will be useful for you.
>
> The hash as it is now can be proved
On Wed, Oct 31, 2018 at 6:58 PM Sebastian Benoit wrote:
On a phone, saw some typos and such, sorry no diff.
[benoit@border2:~]$ cat before
> RDE memory statistics
> 715727 IPv4 unicast network entries using 27.3M of memory
> 58953 IPv6 unicast network entries using 3.1M of memory
>
On Sun, Sep 16, 2018 at 1:15 PM, Johan Huldtgren
wrote:
> On 2018/09/16 10:52, David Higgs wrote:
>> On Sun, Sep 16, 2018 at 10:17 AM, David Higgs wrote:
>>> On Sat, Sep 15, 2018 at 10:05 PM, Philip Guenther
>>> wrote:
>>>> On Sat, Sep 15, 2018 at 11:
On Sun, Sep 16, 2018 at 10:17 AM, David Higgs wrote:
> On Sat, Sep 15, 2018 at 10:05 PM, Philip Guenther wrote:
>> On Sat, Sep 15, 2018 at 11:59 AM David Higgs wrote:
>>>
>>> I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
>>> wi
On Sat, Sep 15, 2018 at 10:05 PM, Philip Guenther wrote:
> On Sat, Sep 15, 2018 at 11:59 AM David Higgs wrote:
>>
>> I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
>> with new features in snapshots, before upgrading my physical hardware.
>>
I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
with new features in snapshots, before upgrading my physical hardware.
This afternoon, I tried updating bsd.rd (amd64, 6.4-beta RAMDISK_CD
#281) and wasn't able to successfully boot it. I had to rely on the
video capture abilit
On Tue, Aug 18, 2015 at 6:22 AM, Mark Kettenis
wrote:
> > Date: Tue, 18 Aug 2015 05:03:19 +
> > From: Miod Vallat
> >
> > > I spent some time today figuting out why the binutils update broke ld
> > > -Z on powerpc. Turns out to be a fairly thorny issue.
> > >
> > > The new binutils discard
If there’s no further work on upd(4) prior to 5.8, at least make the man page
reflect present reality.
- Update list of supported sensors, re-sorted by source file occurrence
- Explain why manual sensorsd.conf(5) intervention can be necessary
- Link to HID power specs
- Prefer “a UPS” over “an UP
On Wed, Jun 10, 2015 at 5:23 AM, Martin Pieuchot wrote:
> On 02/06/15(Tue) 22:36, David Higgs wrote:
> > Here are some new sensors for upd(4) devices. All exist on my device
> except AtRateTimeToEmpty, which still seemed a logical addition given that
> AtRateTimeToFull is
On Wed, Jun 10, 2015 at 5:23 AM, Martin Pieuchot wrote:
> On 02/06/15(Tue) 22:36, David Higgs wrote:
> > Here are some new sensors for upd(4) devices. All exist on my device
> except AtRateTimeToEmpty, which still seemed a logical addition given that
> AtRateTimeToFull is
Here are some new sensors for upd(4) devices. All exist on my device except
AtRateTimeToEmpty, which still seemed a logical addition given that
AtRateTimeToFull is already present.
- AtRateTimeToEmpty
- RunTimeToEmpty
- NeedReplacement
- Overload
If anyone had an AtRate sensor, it was probably
On May 11, 2015, at 9:02 PM, David Higgs wrote:
>
>> On May 11, 2015, at 8:21 PM, David Higgs > <mailto:hig...@gmail.com>> wrote:
>>
>> On Mon, May 11, 2015 at 8:07 PM, Alexander Hall > <mailto:alexan...@beard.se>>wrote:
>> Upgrading to the
> On May 11, 2015, at 8:21 PM, David Higgs wrote:
>
> On Mon, May 11, 2015 at 8:07 PM, Alexander Hall <mailto:alexan...@beard.se>>wrote:
> Upgrading to the latest snapshot, I noticed my upd sensors had been
> disturbingly crippled.
>
> uhidev0 at uhub4 port
On Mon, May 11, 2015 at 8:07 PM, Alexander Hall wrote:
> Upgrading to the latest snapshot, I noticed my upd sensors had been
> disturbingly crippled.
>
> uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev
> 2.00/1.00 addr 2
> uhidev0: iclass 3/0, 32 report ids
> upd0 at u
> On Apr 30, 2015, at 7:09 AM, Martin Pieuchot wrote:
>
> On 24/04/15(Fri) 20:48, David Higgs wrote:
>> This is the final patch in the series.
>>
>> Utilize the pending flags and report callback for their intended purpose -
>> to process async behavior.
>&
On Thu, Apr 30, 2015 at 7:09 AM, Martin Pieuchot wrote:
> On 24/04/15(Fri) 20:48, David Higgs wrote:
> > This is the final patch in the series.
> >
> > Utilize the pending flags and report callback for their intended purpose
> - to process async behavior.
> >
>
This is the big change that puts all the previous work together.
When a sensor update is needed, mark its report as pending; do this in
dependency order. When a report fails to query/reply, mark it and its children
as invalid. When the BatteryPresent says there is no battery, mark its
childre
Divide sensors into two tables - normal sensors and battery dependent sensors.
Build the sensor dependency tree - every sensor has an SLIST of dependent
children.
Also, don’t bother looking for battery dependent sensors at device attach, it
doesn’t seem helpful.
(Someone please correct me if
Locate sensors in table order - by parsing the USB descriptor multiple times -
instead of in the order they exist in the USB descriptor.
This will greatly ease construction of a sensor dependency tree, in the next
diff.
--david
--- a/upd.c
+++ b/upd.c
@@ -86,7 +86,6 @@ struct upd_softc {
Huge thanks to all devs who provided initial feedback in spite of my
inconsistent development pace, especially mpi.
This was mainly a bugfix/infrastructure effort. There's still plenty of
work to do on new features - better sensor units, new sensors, maybe some
sysctls.
Happy to accept bug repor
Split out sensor value update now, since sensor updating will become more
complex.
Also, avoid potential signed/unsigned and truncation errors. Sensor values are
int64_t wide, so put them to work.
--david
--- a/upd.c
+++ b/upd.c
@@ -101,6 +101,8 @@ int upd_detach(struct device *, int);
vo
This is the final patch in the series.
Utilize the pending flags and report callback for their intended purpose - to
process async behavior.
Apply splusb() to ensure report callbacks can't fire before their data
structures have been properly updated. This only needs to happen in
upd_refresh()
On Fri, Apr 24, 2015 at 8:43 PM, David Higgs wrote:
> Associate sensors with the reports they are updated by. Only the reports
> that have sensors will be enabled, so the enabled field becomes redundant.
>
> An important but subtle side-effect is that because the sensor tree is
&
Associate sensors with the reports they are updated by. Only the reports that
have sensors will be enabled, so the enabled field becomes redundant.
An important but subtle side-effect is that because the sensor tree is
constructed depth-first, each report SLIST will contain sensors in dependenc
Should be pretty straightforward.
--david
--- a/upd.c
+++ b/upd.c
@@ -39,6 +39,8 @@
#define DPRINTF(x)
#endif
+#define DEVNAME(sc)((sc)->sc_hdev.sc_dev.dv_xname)
+
struct upd_usage_entry {
uint8_t usage_pg;
uint8_t usage_id;
@@ -164,12 +166
Features of this diff:
- All upd(4) reports are queried asynchronously
- Use pending status to prevent duplicate usb queries
- No apparent changes from end-user point of view
Note: depends on the previous upd(4) LIST diff, not yet committed.
As usual, feedback and comments are welcome.
--david
On Apr 1, 2015, at 9:23 AM, David Higgs wrote:
> On Wed, Apr 1, 2015 at 7:52 AM, Martin Pieuchot wrote:
> On 31/03/15(Tue) 23:06, David Higgs wrote:
> > This was much more straightforward than expected.
> >
> > - Replace an array with a LIST of allocated sensors.
On Wed, Apr 1, 2015 at 7:52 AM, Martin Pieuchot wrote:
> On 31/03/15(Tue) 23:06, David Higgs wrote:
> > This was much more straightforward than expected.
> >
> > - Replace an array with a LIST of allocated sensors.
> > - Remove or rescope variables counting sensors.
This was much more straightforward than expected.
- Replace an array with a LIST of allocated sensors.
- Remove or rescope variables counting sensors.
- Allocated sensors are always attached.
- Drop an unnecessary size calculation.
Thanks.
--david
--- a/upd.c
+++ b/upd.c
@@ -23,6 +23,7 @@
#inc
First in what will probably be a slow trickle, as I split my original big diff
into more-easily reviewed chunks and test each in sequence.
This patch makes upd_attach less confusing:
1. Ignore all bogus report IDs up front, they shouldn't be queried.
2. When a sensor is attached, it will be found
On Mon, Mar 9, 2015 at 6:04 AM, Martin Pieuchot
wrote:
> On 05/03/15(Thu) 12:25, David Higgs wrote:
> >
> > On Mar 3, 2015, at 8:44 AM, David Higgs wrote:
> >
> > > With much help from mpi@, I have made a first big step towards
> improving upd(4). I'm
On Mar 3, 2015, at 8:44 AM, David Higgs wrote:
> With much help from mpi@, I have made a first big step towards improving
> upd(4). I’m not sure when tree lock ends, but I’m still happy to accept
> feedback if right now isn’t the time to commit. There’s plenty more to do,
> but
With much help from mpi@, I have made a first big step towards improving
upd(4). I’m not sure when tree lock ends, but I’m still happy to accept
feedback if right now isn’t the time to commit. There’s plenty more to do, but
I’d like to get this ironed out before moving on.
New behavior with t
On Feb 13, 2015, at 7:29 AM, David Higgs wrote:
> On Friday, February 13, 2015, Martin Pieuchot wrote:
> On 13/02/15(Fri) 00:28, David Higgs wrote:
> > I guess nobody else has tried calling uhidev_get_report_async() yet. :)
> >
> > First I was getting a NULL pointer d
On Feb 13, 2015, at 7:29 AM, David Higgs wrote:
> On Friday, February 13, 2015, Martin Pieuchot wrote:
> On 13/02/15(Fri) 00:28, David Higgs wrote:
> > I guess nobody else has tried calling uhidev_get_report_async() yet. :)
> >
> > First I was getting a NULL pointer d
On Friday, February 13, 2015, Martin Pieuchot
wrote:
> On 13/02/15(Fri) 00:28, David Higgs wrote:
> > I guess nobody else has tried calling uhidev_get_report_async() yet. :)
> >
> > First I was getting a NULL pointer deref in the uhidev async callback.
> >
I guess nobody else has tried calling uhidev_get_report_async() yet. :)
First I was getting a NULL pointer deref in the uhidev async callback.
Then I realized that due to USBD_NO_COPY, xfer->buffer was always
NULL. Next, I tried to use the DMA buffer, but I ended up in DDB in a
very cryptic way.
On Fri, Jan 9, 2015 at 2:07 PM, Martin Pieuchot wrote:
> On 09/01/15(Fri) 12:36, David Higgs wrote:
>> On Fri, Jan 9, 2015 at 9:00 AM, Martin Pieuchot
>> wrote:
>> > As pointed out by David Higgs, uhidev report functions do a lot of
>> > memory allocations and
On Fri, Jan 9, 2015 at 9:00 AM, Martin Pieuchot wrote:
> As pointed out by David Higgs, uhidev report functions do a lot of
> memory allocations and copies between buffers. This is not uncommon
> in USB land due to way DMA buffers are handled.
>
> One way to reduce the number
On Fri, Dec 19, 2014 at 8:55 AM, Martin Pieuchot wrote:
> On 19/12/14(Fri) 08:04, David Higgs wrote:
>> Split upd_update_sensors() behavior to gather all values prior to updating
>> sensor contents.
>>
>> Because sensors were updated in report_ID order, it could
Split upd_update_sensors() behavior to gather all values prior to updating
sensor contents.
Because sensors were updated in report_ID order, it could take multiple passes
of upd_refresh() to update some sensors. Specifically, battery-related sensors
“prior” to a change in BatteryPresent would
On Fri, Dec 19, 2014 at 7:17 AM, Martin Pieuchot wrote:
> Hello David,
>
> On 18/12/14(Thu) 00:45, David Higgs wrote:
>> While my device does not seem to provide AtRateTimeToFull or
>> AtRateTimeToEmpty, it does have RunTimeToEmpty. Then I found that
>> SEN
On Dec 18, 2014, at 1:48 PM, David Higgs wrote:
> Bah. One of those should be (muAh).
>
Take two.
--david
Index: sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.33
diff -u -p -r1.33 sen
Bah. One of those should be (muAh).
--david
For consistency.
--david
Index: sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.33
diff -u -p -r1.33 sensors.h
--- sensors.h 4 Nov 2013 02:41:49 - 1.33
+++ sensors.h 18 Dec 2014 18:16:07 -000
While my device does not seem to provide AtRateTimeToFull or AtRateTimeToEmpty,
it does have RunTimeToEmpty. Then I found that SENSOR_TIMEDELTA values are in
nanoseconds and that scaling for them was never implemented correctly.
I am confused by the spec [1], though; see 4.2.5 - Battery Measure
First, I think the BatteryPresent check has a signedness problem. Second, I
think that it should check for sensor validity too, so it doesn’t use stale
values if BatteryPresent somehow goes straight from present to invalid.
This diff should fix both things, in theory. Compiled and running with
Now that my upd(4) is working (thanks to all involved), I’m looking to improve
behavior a bit. Let’s add some state transitions to the sensors.
Feedback is welcome.
--david
## before
[vm@vm usb]$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (Charging), OK
hw.sensors.upd0.indicator1=O
On Thu, Dec 11, 2014 at 6:22 AM, Martin Pieuchot wrote:
> Thanks for all your comments. I though a bit more about this change and
> decided to:
>
> - Simply return the number of bytes written/read upon success and -1
> otherwise (à la read/write). This allows us to remove some usages
>
On Dec 9, 2014, at 9:53 AM, David Higgs wrote:
> On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson wrote:
>>
>> I was thinking more that it might be better for sensorsd internally
>> to treat state transitions of "indicator" sensors like it treats
>> statu
On Dec 8, 2014, at 6:07 PM, Martin Pieuchot wrote:
> On 08/12/14(Mon) 09:35, David Higgs wrote:
>> On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot
>> wrote:
>> [...]
>>> Now I'd like to finish the transition that started with the import of
>>> upd
On Tue, Dec 9, 2014 at 9:19 AM, Mark Kettenis wrote:
>> Date: Tue, 9 Dec 2014 14:12:20 +
>> From: Stuart Henderson
>>
>> On 2014/12/09 08:37, David Higgs wrote:
>> > Working and non-working dmesgs from the same VM below. Let me know if
>> > any more
On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson wrote:
> On 2014/12/09 09:36, David Higgs wrote:
>> On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
>> > On 2014/12/08 15:04, David Higgs wrote:
>> >> As per an earlier thread on misc@, this fixes sen
I was playing with afl a few weeks ago and found this. I believe it is
triggered by non-sequential timestamp records, but I didn’t dig into it or run
afl for particularly long. The patch below fixed all the crashes afl had found
up to that point.
The string used doesn’t matter, ‘crmsg’ just n
On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
> On 2014/12/08 15:04, David Higgs wrote:
>> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
>> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
>> undocumented and confusing, it i
Working and non-working dmesgs from the same VM below. Let me know if
any more info is needed. If this is already known, sorry for the
noise.
--david
# does not work
OpenBSD 5.6-current (RAMDISK_CD) #555: Tue Dec 9 00:50:21 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/
On Mon, Dec 8, 2014 at 6:07 PM, Martin Pieuchot wrote:
> On 08/12/14(Mon) 09:35, David Higgs wrote:
>> On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot
>> wrote:
>> [...]
>> > Now I'd like to finish the transition that started with the import of
>>
As per an earlier thread on misc@, this fixes sensorsd.conf(5) parsing of
SENSOR_INDICATOR values. Since parsing as integers was both undocumented and
confusing, it is no longer supported. Also, bail on error if the high/low
values don’t create a valid range.
This mimics existing behavior, bu
On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot wrote:
> On 08/12/14(Mon) 09:02, David Higgs wrote:
>> On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot
>> wrote:
>> > The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in
>> > usbd_transfer_comp
On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot wrote:
> The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in
> usbd_transfer_complete() so the HCD should only set the status to
> USBD_NORMAL_COMPLETION, see below.
>
> Concerning your broken firmware, what we should do is change
On Dec 4, 2014, at 4:30 PM, David Higgs wrote:
> I am trying to figure out how to handle the buggy USB firmware in my UPS (see
> misc@ thread from last week). With some kernel debug enabled, I see
> "usb_transfer_complete: short transfer 3<5" messages. Since the
&
I am trying to figure out how to handle the buggy USB firmware in my UPS (see
misc@ thread from last week). With some kernel debug enabled, I see
"usb_transfer_complete: short transfer 3<5" messages. Since the BatteryPresent
sensor could not be read, all battery-related sensors were forced int
Please ignore the previous email to misc. I believe the tm_mon part is still
necessary and hope that I’ve rediscovered how to send inline diffs reliably.
--david
Index: newsyslog.c
===
RCS file: /cvs/src/usr.bin/newsyslog/newsyslog
On Mon, Aug 18, 2014 at 6:24 PM, David Gwynne wrote:
> On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
>> i think i'll try to find the sk at work and wire it up. its just annoying
>> cos im pretty sure its sr optics with sc connectors.
>>
>> thanks for testing.
>
> how's this one?
>
As of lib/libc/time/strptime.c r1.15, certain conversions will perform
calculations using the provided tm_mday value, which will frequently
produce incorrect values for tm_mday and tm_yday. Apologies in
advance for the mangled patch.
Thanks.
--david
Compare runs of the test program below:
/* s
On Jan 25, 2014, at 12:48 AM, David Higgs wrote:
On Fri, Jan 24, 2014 at 4:24 AM, Henning Brauer
wrote:
* Henning Brauer [2014-01-24 05:50]:
i need this tested on an sk(4).
I don't have that hardware at all.
this gets rif od a slight little bit more.
Resurrected an old box, k
On Fri, Jan 24, 2014 at 4:24 AM, Henning Brauer
wrote:
> * Henning Brauer [2014-01-24 05:50]:
>> i need this tested on an sk(4).
>> I don't have that hardware at all.
>
> this gets rif od a slight little bit more.
>
Resurrected an old box, kernel compile w/ patch is underway. Should
be able to
Long time user, first time patch submission. I can send this again after tree
lock, but feedback is welcome in the meantime.
I started trying to fix PR 6006 and felt like there was progress being made
for a while. I was pretty sure that x_file_glob function shouldn't have
stripped backslashes be
72 matches
Mail list logo