Re: touchpad input driver: test results

[Ulf Brosziewski]

As people might want to know what they have worked for, it's probably
time for a summary of the first test results and my conclusions.
(But please don't get that wrong: more tests and reports are and will be
welcome.)

Hardware:  Most tests were made with (PS/2) Synaptics touchpads, and it
seems there are no problems with common models of "OpenBSD laptops".
Few quirks and bugs have been reported for older and less common ones,
and concern things that should be handled by the hardware driver.  Alps
and Elantech models are rare, and it looks like most Mac users are on
holiday.

Driver mechanisms:  No serious problem has come up.  It has been
observed that there are (too) long delays between the start of a scroll
gesture and the first scroll event.  I'm already testing an improved
version of the handler.  There will still be a short delay, because
it reduces the risk that you produce scroll events unintentionally.

Features:  Not surprisingly, some people are missing certain features.
What has been mentioned is 1) "disable-while-typing", 2) edge areas
(where initial contacts don't move the pointer or generate tap events),
3) multi-finger clicks, and 4) "coasting" (that is, scrolling continues
for some time after the scrolling fingers have been lifted).  Up to now
my impression is that 1) and/or 2) could be prominent, maybe 3).
However, there are no decisions about additional features yet, each one
would need some care.

1) and 2) are different approaches to the same task: suppressing outputs
of accidental contacts, usually palm or thumb contacts, so in this
context one might also think of: 5) palm and thumb detection based on
contact width, pressure, and other attributes, perhaps.  1) is based on
a simple principle, but it needs coordination with another driver, and I
am not sure whether it is a good solution, or despair.  What's a
reasonable timeout here?  If it's too short, it only mitigates the
problem, if it's too long, it can be a nuisance.  5) might work well for
some users, with some touchpads, but it may be difficult to find useful
generalizations.  I'm currently checking variants of 2), the basic
mechanism is already present in the driver (it's required for software
buttons and edge scroll areas).  But again, it's too early for
conclusions, and surely we want to avoid a patchwork of half-general and
half-successful solutions.

Default configuration:  The defaults, including the "hidden" ones, seem
to be acceptable for many models.  I will increase the default scroll
speed (moderately).  In some cases, the height of the button area on
clickpads is problematic.  This is not as trivial as it may seem.
Coordinate limits are not always correct, and resolution values can be
unreliable - if they are present at all.  There is actually a good deal
of guess work in the configuration.  Improving that will need more work
on the hardware drivers.

As I have written, not all touchpad drivers cooperate with the input
driver up to now.  I hope this will change soon.  It's not ready yet,
but some work on imt/hidmt has already been done, with help of Remi.

Thanks again for the friendly, competent, and helpful feedback!


On 07/31/2017 11:02 PM, Ulf Brosziewski wrote:
> In the long run the synaptics driver, which handles touchpad inputs in
> X, may be a dead end of the input framework, and it's time to prepare
> an alternative.  The kernel contains an internal touchpad input driver
> now, it's a part of wsmouse(4).  It provides standard features -
> two-finger/edge scrolling, software buttons for clickpads, tapping -
> and various kinds of plankton required for usability.
> 
> If you have a new snapshot (from July 27 or later) on a laptop with a
> Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with
> tests [...]

Re: Using USB headsets

[Christian Weisgerber]

On 2017-08-16, Norman Golisz  wrote:

> I'm trying to figure out how to get my USB headset (Plantronics C310)
> to work.
>
> I can't hear anything, nor does the microphone work. I fiddled with
> different mixerctl settings to no avail, and I'm not even sure my
> headset had been detected at all, as the available options to set
> don't change, while I plug or unplug the device[1].

> dmesg[2] happily reports it detected and configured the device:
>
> uaudio0 at uhub0 port 1 configuration 1 interface 0 "Plantronics Plantronics 
> C310" rev 2.00/1.35 addr 2
> uaudio0: audio rev 1.00, 7 mixer controls
> audio1 at uaudio0

My guess is that all your audio commands actually refer to...

> audio0 at azalia0

... instead of audio1.  If you want to use only the headset, the
easiest fix may be to switch the /dev/{audio,audioctl,mixer} symlinks
from the *0 devices to the *1 ones.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Install UEFI with softraid: How do I create the UEFI boot partition in the installer? And sth quirky in /install .

[Thomas Bohl]

> The standard way to install crypto is to go with the "(S)hell" option at boot.
> 
> In the MBR days it would be "fdisk -i sd0", now should be with the GPT option 
> on so "fdisk -ig sd0".
> 
> Doing this, importantly, no "EFI Sys" partition is created.

# dd if=/dev/zero of=/dev/sd0c bs=1m count=10
# fdisk -igy -b 960 sd0

Does that change anything?



smime.p7s
Description: S/MIME Cryptographic Signature

Re: iwn0: no link after 6.1 upgrade

[Christian Weisgerber]

On 2017-08-19, Stefan Sperling  wrote:

>> Yes, I have double-checked, this is what is shown in the Web GUI.
>> "Authentication PassPhrase Settings" : "WPA-Personal"
>> "WPA Mode" : "WPA2 Only"
>> "Cipher Type" : "TKIP"
>
> Please set Cipher Type to 'AUTO' or 'AES'. Then it should work.
> TKIP is used with WPA1 only.

The cheat sheet I kept for my DAP-2310 says:

...
  - Wireless Settings
SSID
Authentication  WPA-Personal
WPA ModeWPA2 only
Cipher Type AES
PassPhrase  
...

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: ftp.eu.openbsd.org no longer accepts anonymous ftp?

[Marc Espie]

On Sat, Aug 19, 2017 at 12:16:14PM +0200, Peter N. M. Hansteen wrote:
> On 08/19/17 11:44, Andreas Thulin wrote:
> > Also, yesterday's
> > 
> > # pkg_add -u
> > 
> > failed for me, apparently for that same reason.
> 
> Yes, that would happen. Then again, changing ftp:// to https:// in
> /etc/installurl would make pkg_add -u work.

https is currently a disaster for pkg_add... unless you really need
the anonymity, stick with http.  proper signatures means there won't
be any package tampering in any case.

Install UEFI with softraid: How do I create the UEFI boot partition in the installer? And sth quirky in /install .

[tinkr]

Dear misc@,

The standard way to install crypto is to go with the "(S)hell" option at boot.

In the MBR days it would be "fdisk -i sd0", now should be with the GPT option 
on so "fdisk -ig sd0".

Doing this, importantly, no "EFI Sys" partition is created.

Am I supposed to know how to add that one, or is there some magic argument to 
fdisk, or some system tool, that I missed, that would do that for me?


Then, disklabel -E sd0 to add a RAID, bioctl it going, and proceed with 
/install .


In my installation, sd0 is the physical harddrive, sd1 is the installation 
media, and sd2 is the softraid.

In the installation, I instruct the installer script that I want to install on 
sd2 .

Its first question is how I want its non-BSD partitioning to be - that is 
"(M)BR, (G)PT or (E)dit". (E)dit takes you into fdisk , pointless.

(G)PT seems to be the right thing, but.. it creates an "EFI Sys" partition 
*within the logical softraid disk* and not on the root partition - obviously.

Therefore I naturally remove the EFI Sys partition (offset 64, size 960, fstype 
MSDOS), which got BSD disklabel designation "i".

I find this behavior of how (G)PT works quirky, though maybe the 
softraid-disklabel logics and the GPT partitioning logics are so deeply 
intertwined, that it still makes sense to run the ordinary GPT initialization 
also on softraids, and then just let the user remove the redundant EFI Sys 
partition that is created within the softraid. Or? Quirky anyhow. Did I 
understand this right?


At the end of the installer, the installer tells me there is no boot partition 
so therefore couldn't install boot code so therefore boot will fail. And boot 
does fail.


Your instruction for how to get this going would be much appreciated.

Thanks!
Tinker

Re: ftp.eu.openbsd.org no longer accepts anonymous ftp?

[Janne Johansson]

Will fix, have to handle strange 1:1 NAT after move to a new ftp.eu.


2017-08-19 12:16 GMT+02:00 Peter N. M. Hansteen :

> On 08/19/17 11:44, Andreas Thulin wrote:
> > Also, yesterday's
> >
> > # pkg_add -u
> >
> > failed for me, apparently for that same reason.
>
> Yes, that would happen. Then again, changing ftp:// to https:// in
> /etc/installurl would make pkg_add -u work.
>
> - P
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
>


-- 
May the most significant bit of your life be positive.

Re: Pinebook (if anyones up for it)

[Jonathan Gray]

On Mon, Aug 21, 2017 at 12:17:20AM +1000, Jonathan Gray wrote:
> On Tue, Aug 15, 2017 at 09:48:14AM -0400, Patrick Wildt wrote:
> > On Mon, Aug 14, 2017 at 10:08:13PM +0300, valerij zaporogeci wrote:
> > > 2017-08-14 10:21 GMT+03:00, Alex Naumov :
> > > > Hello,
> > > >
> > > > there is one enthusiast, who wants to make it possible:
> > > > http://openbsd-archive.7691.n7.nabble.com/Working-on-support-for-Pinebook-td318562.html
> > > >
> > > > I don't know the current state, but I also have a Pinebook and would
> > > > like to run OpenBSD on it.
> > > >
> > > >
> > > > Some info you can find there: https://www.openbsd.org/arm64.html
> > > > ==
> > > > The Pine64 currently requires an image based on a non-redistributable
> > > > boot0 file from Allwinner to be installed on the system disk. This
> > > > will hopefully be resolved by a replacement in a future U-Boot
> > > > release. The install media does not include these boot images or a
> > > > Pine64 device tree. For similar reasons we do not provide install
> > > > media for the Firefly-RK3399 either.
> > > > ==
> > 
> > Correction: The problem of the boot0 file has been solved thanks to
> > changes in u-boot.  Work on install media for the Pine64 is now in
> > progress, without unredistributable blobs.
> 
> pine64 firmware that doesn't require boot0 is included in
> https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot61.fs
> 
> Looking for testers.
> 

Though the pinebook may require a different device tree
https://patchwork.kernel.org/patch/9591501/

And will likely require 3.3v serial instead of video
http://linux-sunxi.org/Pine_Pinebook#Adding_a_serial_port

Re: Pinebook (if anyones up for it)

[Jonathan Gray]

On Tue, Aug 15, 2017 at 09:48:14AM -0400, Patrick Wildt wrote:
> On Mon, Aug 14, 2017 at 10:08:13PM +0300, valerij zaporogeci wrote:
> > 2017-08-14 10:21 GMT+03:00, Alex Naumov :
> > > Hello,
> > >
> > > there is one enthusiast, who wants to make it possible:
> > > http://openbsd-archive.7691.n7.nabble.com/Working-on-support-for-Pinebook-td318562.html
> > >
> > > I don't know the current state, but I also have a Pinebook and would
> > > like to run OpenBSD on it.
> > >
> > >
> > > Some info you can find there: https://www.openbsd.org/arm64.html
> > > ==
> > > The Pine64 currently requires an image based on a non-redistributable
> > > boot0 file from Allwinner to be installed on the system disk. This
> > > will hopefully be resolved by a replacement in a future U-Boot
> > > release. The install media does not include these boot images or a
> > > Pine64 device tree. For similar reasons we do not provide install
> > > media for the Firefly-RK3399 either.
> > > ==
> 
> Correction: The problem of the boot0 file has been solved thanks to
> changes in u-boot.  Work on install media for the Pine64 is now in
> progress, without unredistributable blobs.

pine64 firmware that doesn't require boot0 is included in
https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot61.fs

Looking for testers.

MPLS BGP VRF

[Mario Gomez]

I am very interested in using the OpenBSD platform for an ISP and as I read
it does MPLS. Download the platform and install it on a serverU with a 10G
card. I'm running MPLS testing between OpenBSD and Junos. I currently have
OSPF, LDP and BGP up. Perform the rdomain configuration to test MPLS-MP VRF.

I see that the routes are propagated to the VRF in Junos but I do not see
OpenBSD mounting the routes received from Junos to rtables. I have read that
OpenBSD only does the verification of the nexthop in the rtable 0. I wanted
to check with you if it is possible to do this configuration against Junos
and to verify that I am doing wrong.

Here I include the configuration of Junos and OpenBSD.


Junos:

set interfaces ge-0/0/0 mtu 1614
set interfaces ge-0/0/0 unit 0 description To-OpenBSD
set interfaces ge-0/0/0 unit 0 family inet address 10.205.1.2/30
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.247.255.51/32
set interfaces lo0 unit 104 family inet address 192.168.100.1/24
set routing-options router-id 10.247.255.51
set routing-options autonomous-system 65535
set protocols mpls interface all
set protocols bgp group mpls type internal
set protocols bgp group mpls local-address 10.247.255.51
set protocols bgp group mpls hold-time 180
set protocols bgp group mpls import rv
set protocols bgp group mpls family inet-vpn unicast
set protocols bgp group mpls export Rrt-Export
set protocols bgp group mpls neighbor 10.247.255.50
set protocols bgp group mpls neighbor 10.247.255.58
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ldp interface all
set policy-options policy-statement Rrt-Export from protocol direct
set policy-options policy-statement Rrt-Export from protocol static
set policy-options policy-statement Rrt-Export from protocol ospf
set policy-options policy-statement Rrt-Export then accept
set policy-options policy-statement rv term a from protocol bgp
set policy-options policy-statement rv term a from validation-database valid
set policy-options policy-statement rv term a then local-preference 110
set policy-options policy-statement rv term a then validation-state valid
set policy-options policy-statement rv term a then accept
set policy-options policy-statement rv term b from protocol bgp
set policy-options policy-statement rv term b from validation-database
invalid
set policy-options policy-statement rv term b then local-preference 9
set policy-options policy-statement rv term b then validation-state invalid
set policy-options policy-statement rv term b then accept
set policy-options policy-statement rv term c from protocol bgp
set policy-options policy-statement rv term c from validation-database
unknown
set policy-options policy-statement rv term c then validation-state unknown
set policy-options policy-statement rv term c then accept
set routing-instances VRF-TEST instance-type vrf
set routing-instances VRF-TEST interface lo0.104
set routing-instances VRF-TEST route-distinguisher 10.247.255.51:104
set routing-instances VRF-TEST vrf-target target:65535:104
set routing-instances VRF-TEST routing-options options syslog level
emergency
set routing-instances VRF-TEST routing-options options syslog level alert
set routing-instances VRF-TEST routing-options options syslog level critical
set routing-instances VRF-TEST routing-options options syslog level error
set routing-instances VRF-TEST routing-options options syslog level warning
set routing-instances VRF-TEST routing-options options syslog level notice
set routing-instances VRF-TEST routing-options options syslog level info
set routing-instances VRF-TEST routing-options options syslog level debug

root> show route table VRF-TEST.inet.0

VRF-TEST.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.25.252/32  *[BGP/170] 00:00:02, localpref 100, from 10.247.255.58
  AS path: I, validation-state: unknown
> to 10.205.1.1 via ge-0/0/0.0, Push 58
192.168.100.0/24   *[Direct/0] 12w3d 16:26:11
> via lo0.104
192.168.100.1/32   *[Local/0] 12w3d 16:26:11
  Local via lo0.104


root> ping routing-instance VRF-TEST 192.168.25.252
PING 192.168.25.252 (192.168.25.252): 56 data bytes
^C
--- 192.168.25.252 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

root> 


OpenBSD


# ifconfig
lo0: flags=8049 mtu 32768
index 8 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet 127.0.0.1 netmask 0xff00
em0: flags=8843 mtu 1500
lladdr 84:44:64:33:94:f2
index 1 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
em1: 

Re: vmm workflow

[Carlos Cardenas]

I found the problem with my config.

6.1 release doesn't have this commit:

commit 6b03ca832af8774eea914a99e4e49c232b169cd4
Author: reyk 
Date:   Thu Apr 6 21:35:22 2017 +

"kernel" got renamed to "boot" in vm.conf but I didn't commit the
parse.y bits.

Found by Pontus Lundkvist

OK deraadt

So I just renamed "boot" to "kernel" and everything is golden.

Verified that -current works with the original config (using "boot").

On 08/19/17 22:32, Mike Larkin wrote:
> On Sat, Aug 19, 2017 at 10:24:57PM -0700, Mike Larkin wrote:
>> On Thu, Aug 17, 2017 at 01:36:33PM -0700, Carlos Cardenas wrote:
>>> Thanks Bryan and Mike.
>>>
>>> I'll stick to what y'all are suggesting.
>>>
>>> Is there a page for the vmm roadmap?  I am interested in advancing vmm and
>>> would like to participate in its development.
>>>
>>
>> not really. people work on what they want to work on, like most of the rest 
>> of
>> openbsd.
>>
>> that being said, diffs to fix bugs like the ones below are welcome. that 
>> would 
>> be a good way to get started.
>>
>> -ml
>>
> 
> PS, the following content in /etc/vm.conf (based on yours) works fine for me.
> 
> ramdisk="/bsd.rd"
> switch "x" {
> add vether0
> }
> 
> vm "tester" {
> boot $ramdisk
> memory 512M
> disable
> interface { switch "x" }
> }
> 
> 
> -ml
> 
>>> +--+
>>> Carlos
>>>
>>> On Aug 17, 2017 12:48, "Mike Larkin"  wrote:
>>>
>>> On Wed, Aug 16, 2017 at 07:50:59PM -0700, Carlos Cardenas wrote:
 Howdy.

 I've been playing around with vmm(4) on 6.1 and have noticed a few
 things that seem odd.

 Take the following vm.conf:
 ramdisk="/home/los/vmm/bsd.rd-current"
 switch "local" {
 add vether0
 }
 vm "test.vm" {
 boot $ramdisk
 disable
 owner los
 memory 2G
 disk "/home/los/vmm/test.vm.img"
 interface { switch "local" }
 }

 Doing vmd -n yields:
 /etc/vm.conf:6: syntax error

 Removing the boot line yields a warning about unused macro (referring
 to ramdisk).

 So now my config is:
 switch "local" {
 add vether0
 }
 vm "test.vm" {
 disable
 owner los
 memory 2G
 disk "/home/los/vmm/test.vm.img"
 interface { switch "local" }
 }

 vmd(8) is happy and am expecting
 vmctl start "test.vm" -b "/home/los/vmm/bsd.rd-current" -c
 to work since all the other params have been defined in vm.conf.

 Instead I get:
 vmctl: starting without disks
 vmctl: starting without network interfaces
 vmctl: start vm command failed: Operation not permitted

 Increasing verbose log on vmd gets me:
 startup
 /etc/vm.conf:4: switch "local" registered
 /etc/vm.conf:11: vm "test.vm" registered (disabled)
 vm_priv_brconfig: interface bridge0 description switch1-local
 vm_priv_brconfig: interface bridge0 add vether0
 vmd_configure: not creating vm test.vm (disabled)
 denied request 3 from uid 1000

 However, if I perform a "doas vmctl start" first (along with
 install) and then define it in vm.conf, "vmctl start 'test.vm'" works as
 expected.

 What is the expected workflow for vmm?

 Any ideas on why the boot $ramdisk line is error'ing out?

 +--+
 Carlos

>>>
>>> You can't yet specify part of the parameter list in vm.conf and override or
>>> supplement that later with command line arguments to vmctl. So the thing
>>> that
>>> is breaking you is the -b option on your command line.
>>>
>>> I don't know why the macro expansion is failing.
>>>
>>> Note that the ability to supplement config options is something we planned
>>> to
>>> do at some point, just haven't got there yet. There are questions to be
>>> answered about how that interacts with the "owner" concept. For now, either
>>> specify all the VM config on the command line, or all of it in vm.conf.
>>> Don't
>>> mix and match.
>>>
>>> -ml
>>

+--+
Carlos