Re: [Patch]: Integrate VA-API into xenocara

2020-01-23 Thread Jonathan Gray
On Fri, Jan 24, 2020 at 04:45:07PM +1100, Jonathan Gray wrote: > On Thu, Jan 23, 2020 at 12:39:29PM +1100, Jonathan Gray wrote: > > On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote: > > > This is a rather large patch that moves my previously submitted > > > VA-API ports into xenocara.

Re: [Patch]: Integrate VA-API into xenocara

2020-01-23 Thread Jonathan Gray
On Thu, Jan 23, 2020 at 12:39:29PM +1100, Jonathan Gray wrote: > On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote: > > This is a rather large patch that moves my previously submitted > > VA-API ports into xenocara. For your convenience, I've inlined > > a diff that shows you all of the

remove spurious checksumming attempts

2020-01-23 Thread richard . n . procter
Hi, dlg@ pointed out what looks to be a spurious call in the bridge to in_proto_cksum_out(). I've checked the stack and found eight such calls I think can be safely removed. in_proto_cksum_out() computes, for packets flagged as needing it, the transport checksum. It skips if the output interf

Re: sunkbd: timeout_add(9) -> timeout_add_msec(9)

2020-01-23 Thread Scott Cheloha
On Sun, Dec 22, 2019 at 01:34:54PM -0600, Scott Cheloha wrote: > As per dev/wscons/wsconsio.h, wskbd_bell_data.period is a count of > milliseconds. > > ok? 1 month bump. > Index: sunkbd.c > === > RCS file: /cvs/src/sys/dev/sun/sunkb

Re: dt(4) and allowkmem

2020-01-23 Thread Theo de Raadt
Sure. There may be some man page locations missing, from a grep: man2/sysctl.2:.It Dv KERN_ALLOWKMEM Pq Va kern.allowkmem man3/sysctl.3:.It Dv KERN_ALLOWKMEM Pq Va kern.allowkmem man7/securelevel.7:.Va kern.allowkmem , Martin Pieuchot wrote: > On 22/01/20(Wed) 14:56, Theo de Raadt wrote: > >

Re: EFI frame buffer > 4GB

2020-01-23 Thread YASUOKA Masahiko
Yes, the diff fixed the problem of my vaio. Thanks, On Fri, 24 Jan 2020 01:52:56 +0100 Mark Kettenis wrote: > Mike Larkin and I came up with the folowing diff that keeps mapping > the framebuffer early. We tested this on a small number of machines > here that have the framebuffer < 4GB. > It'd b

Re: MSI-X & Interrupting CPU > 0

2020-01-23 Thread Jonathan Matthew
On Thu, Jan 23, 2020 at 11:28:50AM +0100, Martin Pieuchot wrote: > I'd like to make progress towards interrupting multiple CPUs in order to > one day make use of multiple queues in some network drivers. The road > towards that goal is consequent and I'd like to proceed in steps to make > it easier

Re: EFI frame buffer > 4GB

2020-01-23 Thread Mark Kettenis
Mike Larkin and I came up with the folowing diff that keeps mapping the framebuffer early. We tested this on a small number of machines here that have the framebuffer < 4GB. It'd be great if we can confirm this also works on machine where it is > 4GB. Thanks, Mark? arch/amd64/compile/GENERIC.

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
On Thu, Jan 23, 2020 at 11:25:51PM +0100, Mark Kettenis wrote: > Since acpi_set_brightness() can be called from anywhere, it should really > use the acpi task queue to do its thing instead of calling AML directly. I didn't know there's an acpi task queue, so that's awesome! I just saw that acpith

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Mark Kettenis
Patrick Wildt schreef op 2020-01-23 08:26: Hi, this is the second attempt of a diff that prepares acpivout(4) to work with the X395. The previous one broke due to recursive ACPI locking. So apparently we cannot change the brightness using the acpivout(4) ACPI methods. Instead we need to cal

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
On Thu, Jan 23, 2020 at 05:03:01PM -0500, Ted Unangst wrote: > Patrick Wildt wrote: > > acpivout_[gs]et_param don't know if they are being called by itself > > or by someone else. I don't need to grab it again, I just need to > > have it before calling an ACPI method. But when acpivout(4) calls >

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Ted Unangst
Patrick Wildt wrote: > acpivout_[gs]et_param don't know if they are being called by itself > or by someone else. I don't need to grab it again, I just need to > have it before calling an ACPI method. But when acpivout(4) calls > itself, it already has it, so taking it again would break it, as it'

Re: ospf6d: simplify lsa_snap()

2020-01-23 Thread Sebastian Benoit
Remi Locherer(remi.loche...@relo.ch) on 2020.01.22 06:49:53 +0100: > On Wed, Jan 22, 2020 at 12:56:00AM +0100, Claudio Jeker wrote: > > On Tue, Jan 21, 2020 at 03:58:58PM +0100, Remi Locherer wrote: > > > On Tue, Jan 21, 2020 at 01:09:30PM +0100, Denis Fondras wrote: > > > > On Tue, Jan 21, 2020 at

Re: cwm: remove menu-ssh

2020-01-23 Thread prx
Using x11/dmeny with à little script like this (to improve) : https://dev.ybad.name/Scripts/mybin/dsshmenu Le 23 janvier 2020 16:01:54 GMT+01:00, Mikhail a écrit : >Can you elaborate on tools for menu-ssh replacement? > >On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen >wrote: >> >> Hi, >> >> I

Re: cwm: remove menu-ssh

2020-01-23 Thread su.root
yeah am not sure I am following the logic here...why install rofi when terminal will suffice On 23/01 18:42, Uwe Werler wrote: > rofi. It's in the ports. > > Am 23. Januar 2020 15:01:54 GMT+00:00 schrieb Mikhail : > >Can you elaborate on tools for menu-ssh replacement? > > > >On Wed, Jan 22, 202

Re: cwm: remove menu-ssh

2020-01-23 Thread Uwe Werler
rofi. It's in the ports. Am 23. Januar 2020 15:01:54 GMT+00:00 schrieb Mikhail : >Can you elaborate on tools for menu-ssh replacement? > >On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen >wrote: >> >> Hi, >> >> I think we've (or at least I have) mused about this for a while; a >> recent mail remind

Re: MSI-X & Interrupting CPU > 0

2020-01-23 Thread Alexandr Nedvedicky
Hello, > > 3. How does interrupting multiple CPUs influence packet processing in > the softnet thread? Is any knowledge required (CPU affinity?) to > have an optimum processing when multiple softnet threads are used? > I think it's hard to tell in advance. IMO we should try to ma

Re: MSI-X & Interrupting CPU > 0

2020-01-23 Thread Martin Pieuchot
On 23/01/20(Thu) 13:38, Mark Kettenis wrote: > Martin Pieuchot schreef op 2020-01-23 11:28: > > [...] > > We currently have 6 drivers using pci_intr_map_msix(). Since we want to > > be able to specify a CPU should we introduce a new function like in the > > diff below or do we prefer to add a new

ieee80211_node diff

2020-01-23 Thread Mikhail
There is no way ic_bgscan_fail can be less then zero, since it's unsigned[1]. Sorry for the attachment - web browser mail in act. [1] - http://bxr.su/OpenBSD/sys/net80211/ieee80211_var.h#251 ieee80211_node.patch Description: Binary data

Re: cwm: remove menu-ssh

2020-01-23 Thread Mikhail
Can you elaborate on tools for menu-ssh replacement? On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen wrote: > > Hi, > > I think we've (or at least I have) mused about this for a while; a > recent mail reminded me that this feature should go - a window manager > doesn't need to parse the ssh known_

Re: MSI-X & Interrupting CPU > 0

2020-01-23 Thread Mark Kettenis
Martin Pieuchot schreef op 2020-01-23 11:28: I'd like to make progress towards interrupting multiple CPUs in order to one day make use of multiple queues in some network drivers. The road towards that goal is consequent and I'd like to proceed in steps to make it easier to squash bugs. I'm cu

Re: dt(4) and allowkmem

2020-01-23 Thread Todd C . Miller
On Thu, 23 Jan 2020 10:03:08 +0100, Martin Pieuchot wrote: > Sure! Diff below does that, ok? Looks good. OK millert@ - todd

Re: cwm: remove menu-ssh

2020-01-23 Thread su.root
ok On 22/01 15:15, Okan Demirmen wrote: > Hi, > > I think we've (or at least I have) mused about this for a while; a > recent mail reminded me that this feature should go - a window manager > doesn't need to parse the ssh known_hosts file for a menu; there are > better tools for this. > > Remo

MSI-X & Interrupting CPU > 0

2020-01-23 Thread Martin Pieuchot
I'd like to make progress towards interrupting multiple CPUs in order to one day make use of multiple queues in some network drivers. The road towards that goal is consequent and I'd like to proceed in steps to make it easier to squash bugs. I'm currently thinking of the following steps: 1. Is

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

2020-01-23 Thread Damien Miller
On Thu, 23 Jan 2020, Damien Miller wrote: > On Thu, 23 Jan 2020, Damien Miller wrote: > > > What information would you like there? We could put the first N listen > > addrs in the proctitle if that would help. > > Maybe like this: > > 63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
On Thu, Jan 23, 2020 at 09:51:11AM +0100, Martin Pieuchot wrote: > On 23/01/20(Thu) 08:26, Patrick Wildt wrote: > > Hi, > > > > this is the second attempt of a diff that prepares acpivout(4) to work > > with the X395. The previous one broke due to recursive ACPI locking. > > > > So apparently we

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Martin Pieuchot
On 23/01/20(Thu) 08:26, Patrick Wildt wrote: > Hi, > > this is the second attempt of a diff that prepares acpivout(4) to work > with the X395. The previous one broke due to recursive ACPI locking. > > So apparently we cannot change the brightness using the acpivout(4) ACPI > methods. Instead we

Re: dt(4) and allowkmem

2020-01-23 Thread Martin Pieuchot
On 22/01/20(Wed) 14:56, Theo de Raadt wrote: > Todd C. Miller wrote: > > > On Wed, 22 Jan 2020 15:12:25 +0100, Martin Pieuchot wrote: > > > > > dt(4) is a debugging interface that allows userland to read kernel > > > addresses. So its access should be restricted by default, just like > > > mem(