This is an updated version of the diff for precision scrolling. It
fixes a bug of the first one (which didn't check the synchronization
state properly), and it improves the filtering (when a scroll gesture
stops and the fingers remain on the touchpad, the first version
could too easily generate
> Date: Mon, 18 Mar 2019 14:49:48 +0100
> From: Frederic Cambus
>
> Hi tech@,
>
> Now that efifb(4) supports remapping the framebuffer in write combining
> mode, it's on par with inteldrm regarding display performance as for as
> rasops(9) is concerned.
>
> Therefore, I'm proposing reverting
W dniu 22.03.2019 o 11:19, Michał Koc pisze:
W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote:
W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote:
On Tue, Mar 12, 2019 at
(better when the right diff is sent...)
ROV has been broken since the configuration reload changes.
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.466
diff -u -p -r1.466 rde.c
--- rde.c 13 Mar
Kristaps Dzonsons wrote:
> >> ... it says the modification time is a time_t. Which means we only
> >> have seconds, not subseconds.
> >
> > Fair enough. The protocol predates common availability of nanosecond
> > file timestamps.
>
> It's worse than that. It's 32-bit time_t.
Your docs say
Kristaps Dzonsons wrote:
> >> ... it says the modification time is a time_t. Which means we only
> >> have seconds, not subseconds.
> >
> > Fair enough. The protocol predates common availability of nanosecond
> > file timestamps.
>
> It's worse than that. It's 32-bit time_t.
Do negative
Paul de Weerd wrote:
> On Fri, Mar 22, 2019 at 11:53:20AM +, Stuart Henderson wrote:
> | This is a more general thing actually, the list of USB drivers is rather
> | haphazard at the moment. List below (to fit <80 cols I've snipped i386
> | which has all drivers present in any other GENERIC
>> ... it says the modification time is a time_t. Which means we only
>> have seconds, not subseconds.
>
> Fair enough. The protocol predates common availability of nanosecond
> file timestamps.
It's worse than that. It's 32-bit time_t.
On Fri, 22 Mar 2019 11:16:00 -0500, Scott Cheloha wrote:
> ... it says the modification time is a time_t. Which means we only
> have seconds, not subseconds.
Fair enough. The protocol predates common availability of nanosecond
file timestamps.
- todd
On Fri, Mar 22, 2019 at 11:53:20AM +, Stuart Henderson wrote:
| This is a more general thing actually, the list of USB drivers is rather
| haphazard at the moment. List below (to fit <80 cols I've snipped i386
| which has all drivers present in any other GENERIC config, amd64 which
| is only
On Fri, Mar 22, 2019 at 10:10:43AM -0600, Todd C. Miller wrote:
> On Fri, 22 Mar 2019 11:04:05 -0500, Scott Cheloha wrote:
>
> > I always forget about the special value shortcut for utimes(2) et al.
> >
> > This is equivalent/simpler/more portable.
>
> That looks good but I wonder why we are not
On Fri, 22 Mar 2019 11:04:05 -0500, Scott Cheloha wrote:
> I always forget about the special value shortcut for utimes(2) et al.
>
> This is equivalent/simpler/more portable.
That looks good but I wonder why we are not preserving the nanosecond
mtime by using st_mtim?
- todd
I always forget about the special value shortcut for utimes(2) et al.
This is equivalent/simpler/more portable.
ok?
Index: receiver.c
===
RCS file: /cvs/src/usr.bin/rsync/receiver.c,v
retrieving revision 1.19
diff -u -p -r1.19
ROV has been broken since the configuration reload changes.
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.466
diff -u -p -r1.466 rde.c
--- rde.c 13 Mar 2019 14:35:39 - 1.466
+++ rde.c
Whoops. I had missed one change to the manpage that's still needed:
the DESCRIPTION section also mentions the supported devices. This now
supports two models, but I don't think it makes sense to turn this
into a list of supported hardware just yet.
Index: umbg.4
The following patch fixes exit codes, which became confused in the
switch from returning a Boolean and an exit code. I actually prefer for
these to become an enum to avoid further confusion, but this just gets
it fixed.
It also documents the return values in each function and unifies the
W dniu 22.03.2019 o 11:19, Michał Koc pisze:
W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote:
W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote:
On Tue, Mar 12, 2019 at
OK
On 2019 Mar 22 (Fri) at 10:04:37 +0100 (+0100), Paul de Weerd wrote:
:Index: GENERIC
:===
:RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
:retrieving revision 1.466
:diff -u -p -r1.466 GENERIC
:--- GENERIC19 Jan
OK
On 2019 Mar 22 (Fri) at 10:04:19 +0100 (+0100), Paul de Weerd wrote:
:
:Index: share/man/man4/umbg.4
:===
:RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
:retrieving revision 1.4
:diff -u -p -r1.4 umbg.4
:---
On 2019/03/22 11:55, Paul de Weerd wrote:
> On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
> | $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
> ${i%%/*}; done
>
> Did you want to only find archs which DO have udcf(4) but not umbg(4)?
> Because not
On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
| $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
${i%%/*}; done
Did you want to only find archs which DO have udcf(4) but not umbg(4)?
Because not all of those in your list have udcf. This adds ubmg
On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
| it's missing on some others too;
|
| $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
${i%%/*}; done
| alpha
| amd64
| arm64
| armv7
| hppa
| landisk
| loongson
| luna88k
| socppc
Yes. I have some of
On 23.2.2019. 10:35, David Gwynne wrote:
> On Fri, Feb 22, 2019 at 09:56:58AM -0300, Martin Pieuchot wrote:
>> On 22/02/19(Fri) 15:01, David Gwynne wrote:
>>> On Thu, Feb 21, 2019 at 04:29:27PM -0300, Martin Pieuchot wrote:
On 21/02/19(Thu) 14:19, David Gwynne wrote:
> right now we add
On 2019/03/22 10:04, Paul de Weerd wrote:
> Index: GENERIC
> ===
> RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.466
> diff -u -p -r1.466 GENERIC
> --- GENERIC 19 Jan 2019 03:24:18 -
W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote:
W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote:
On Tue, Mar 12, 2019 at 03:19:56PM +0100, Otto Moerbeek wrote:
I also
Bonus diff - make explicit in the GENERIC configs that already have
umbg(4), that this driver now supports DCF600USB too
Index: i386/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision
Index: usbdevs.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.707
diff -u -p -r1.707 usbdevs.h
--- usbdevs.h 24 Feb 2019 17:35:44 - 1.707
+++ usbdevs.h 22 Mar 2019 07:48:28 -
@@
Index: GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.466
diff -u -p -r1.466 GENERIC
--- GENERIC 19 Jan 2019 03:24:18 - 1.466
+++ GENERIC 22 Mar 2019 08:10:33 -
@@
Index: share/man/man4/umbg.4
===
RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
retrieving revision 1.4
diff -u -p -r1.4 umbg.4
--- share/man/man4/umbg.4 16 Jul 2013 16:05:49 - 1.4
+++ share/man/man4/umbg.4
Index: usbdevs
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.695
diff -u -p -r1.695 usbdevs
--- usbdevs 24 Feb 2019 17:35:29 - 1.695
+++ usbdevs 20 Mar 2019 11:55:44 -
@@
Hi all,
After Peter J. Philipp asked about Meinberg DCF clock support on misc@
in https://marc.info/?l=openbsd-misc=155205024420585=2 I was also
interested in the question he asked. After some consideration, I
decided to try, so I bought a Meinberg DCF600USB which was delivered
yesterday. I
On Tue, Mar 19 2019 15:28:48 -0600, Todd C. Miller wrote:
> On Tue, 19 Mar 2019 23:24:24 +0200, Lauri Tirkkonen wrote:
>
> > I might be blind, but 'grep -r send-mail /usr/ports/pobj/nmh-1.7.1'
> > comes up empty for me after 'make extract' in /usr/ports/mail/nmh?
>
> It looks like spost.c is
32 matches
Mail list logo
