Re: issues with touchpad after update
ci4...@gmail.com (Chavdar Ivanov) writes: >I am not aware if we have some support for accelleration. The X server does acceleration for you. In xorg.conf try something like: Section "InputDevice" Identifier "Mouse0" Driver "wsmouse" Option "Accelerationprofile" "4" EndSection -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: issues with touchpad after update
Just to add my 2c - the Synaptics behaviour on -current has been much much better since these recent changes; I am not too bothered by the multitouch gestures, although two finger scrolling would be nice. These may work, I haven't tried changing any hw.synaptics sysctls yet. The random jumps towards the bottom-left corner have all but disappeared, for example (these happen under Windows 10 also, using the Microsoft precision touchpad driver, not the original Synaptics one). I am not aware if we have some support for accelleration. It is a bit annoying, it takes 3-4 full drags on the touchpad to cross the screen diagonally. Anyway, I stopped attaching a mouse to my laptop when I boot into NetBSD. On Thu, 6 Dec 2018 at 08:57 Martin Husemann wrote: > On Thu, Dec 06, 2018 at 07:52:52AM +1030, Brett Lymn wrote: > > I think Martin said he was going to look at this - again, I only have a > > clickpad on my laptop so it is hard to test. > > Yes. > > > > I think it is just a software feature, maybe not even convenient - I > am > > > not accustomed to it because e.g. ThinkPads do not have it. > > > > > > > It could be a software feature - if it is then we can do the same sort > > of thing I did for emulating 3 buttons on a clickpad (by default that > > only reports a left click which is why I started hacking on the driver > > in the first place...) > > It is (or so I think). It just reserves the rightmost n "pixel" > (where n should be a sysctl) for the scroll area and translates any > slides there into scroll events. > > The windows driver also offers a horizontal scroll area at the bottom, > but those is not marked on the hardware and probably not of much use. > The vertical scroll area is optically/harptically marked on my > notebook. > > Martin >
daily CVS update output
Updating src tree: P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_znode.c P src/lib/libc/arch/aarch64/softfloat/softfloat.h P src/lib/libc/stdlib/strtonum.c P src/share/misc/acronyms.comp P src/sys/arch/aarch64/include/param.h P src/sys/arch/x86/include/pmap.h P src/sys/arch/x86/x86/svs.c P src/sys/dev/pci/ixgbe/if_sriov.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/dev/pci/ixgbe/ixgbe.h P src/sys/dev/pci/ixgbe/ixgbe_82599.c P src/sys/dev/pci/ixgbe/ixgbe_api.c P src/sys/dev/pci/ixgbe/ixgbe_api.h P src/sys/dev/pci/ixgbe/ixgbe_features.h P src/sys/dev/pci/ixgbe/ixgbe_netbsd.c P src/sys/dev/pci/ixgbe/ixgbe_netbsd.h P src/sys/dev/pci/ixgbe/ixgbe_phy.c P src/sys/dev/pci/ixgbe/ixgbe_type.h P src/sys/dev/pci/ixgbe/ixgbe_x550.c P src/sys/dev/pci/ixgbe/ixgbe_x550.h P src/sys/kern/kern_proc.c P src/usr.bin/w/uptime.1 P src/usr.bin/w/w.1 Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52439338 Dec 7 03:03 ls-lRA.gz
Re: issues with touchpad after update
On Fri, Dec 07, 2018 at 01:04:02PM +1030, Brett Lymn wrote: > > Yes, horizontal scroll was a thing once upon a time. I don't think I > have seen any recent mice that offer it as a feature, probably too hard > to use sanely. > After a moment of research - windows does horizontal scroll as shift-mousewheel. Probably a bit of xinput magic would emulate that. -- Brett Lymn "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: issues with touchpad after update
On Thu, Dec 06, 2018 at 09:57:31AM +0100, Martin Husemann wrote: > > It is (or so I think). It just reserves the rightmost n "pixel" > (where n should be a sysctl) for the scroll area and translates any > slides there into scroll events. > That should be very easy to implement - you can probably just modify the if statement I have there for two finger scroll change it from if (finger-width > number) to if (finger-width > number) or (y-position > boundary_number) so the code then starts reporting y motion as z motion. > The windows driver also offers a horizontal scroll area at the bottom, > but those is not marked on the hardware and probably not of much use. > The vertical scroll area is optically/harptically marked on my > notebook. > Yes, horizontal scroll was a thing once upon a time. I don't think I have seen any recent mice that offer it as a feature, probably too hard to use sanely. -- Brett Lymn "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: issues with touchpad after update
On Thu, Dec 06, 2018 at 11:46:50AM +, Chavdar Ivanov wrote: > Just to add my 2c - the Synaptics behaviour on -current has been much much > better since these recent changes; Cool :) > I am not too bothered by the multitouch > gestures, although two finger scrolling would be nice. These may work, I > haven't tried changing any hw.synaptics sysctls yet. Yes, they should work ok now, just make sure you have updated the driver within the last day or so. > The random jumps > towards the bottom-left corner have all but disappeared, for example (these > happen under Windows 10 also, using the Microsoft precision touchpad > driver, not the original Synaptics one). > Yes, that was a nasty bug nailed early on - there was jump detection in the code but it only checked one direction, wrapping the jump size in an abs() made things a lot better. > I am not aware if we have some support for accelleration. It is a bit > annoying, it takes 3-4 full drags on the touchpad to cross the screen > diagonally. Anyway, I stopped attaching a mouse to my laptop when I boot > into NetBSD. > Yes - the defaults make the cursor slow for me too. It would suggest playing with: hw.synaptics.scale_x hw.synaptics.scale_y The lower the numbers the faster the cursor will move. I set both of them to 4 in my sysctl.conf - the defaults are 16. I am guessing they were set back in the days when the trackpad resolutions were a lot lower. I think it would be wise to leave the defaults as they are on the basis it is better to have a slow mouse initially and give people the control to increase the speed rather than have a cursor zipping all over the screen making it impossible to use. -- Brett Lymn "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: MSI/MSI-X implementation and interrupt handling on i386/amd64
Hi Geoff, Saitoh-san pointed me at this email. I've been looking at MSI briefly - should have some work in place to sort out this situation. About your specific situation: Geoff Wing writes: > Hi, > brief background: on an amd64 VM (1 CPU on VMWare ESXi) I had a network > interface (vmx) failing because it could not get an interrupt slot. The > vmx wants 3 interrupts per interface (tx/rx/link-state). I had a few > on an admin machine and one started failing when ahcisata was changed to > use MSI (not ahcisata's fault, obviously). > > On i386/amd64 each CPU has a 32 bitmask for interrupts (1 bit per) - but > 16 of the 32 are reserved for legacy IRQs (on the first CPU). MSI-X allows > for 2048 interrupts. On a physical machine with many CPUs the MSI interrupts > are farmed out across the different CPUs so would not be apparent to most. > (and no problem for those 65+ core machines). > > For my personal use, I've hacked around by ignoring the reserved legacy IRQ > region because it's not relevant to me in my VM with MSI/MSI-X. Other > people using single CPU VMs may start bumping into this issue so just > making people aware. I haven't looked into changing how interrupts are > handled or if there would be significant performance penalty. > You could have a stopgap fix by just using a 64 bit mask and equivalent supporting data structures instead of the 32bit one. You'll probably need to also look at spl.S assembler primitives that access the pending bitmask via assembler instructions and teach them how to do this on a 64bit pending string. The right thing to do is to stop using a bit mask entirely, and using a bit more scalable Data structure for this. This isn't trivial though - the assembler stuff will be harder to maintain correctness than a straightup buslocked bitscan/compare etc. In any case, I'll report back when I get around to this. Many Thanks, -- ~cherry
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > sbin/gpt/t_gpt:migrate_disklabel This was a false alarm - sorry about that. Looks like the testbed used some idle time to fill in a gap in the test history from November, and accidentally rediscovered a test failure that had already been fixed. -- Andreas Gustafsson, g...@gson.org
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: sbin/gpt/t_gpt:migrate_disklabel The above test failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 801 revisions were committed, by the following developers: jakllsch mrg Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.11.html#2018.11.11.23.04.27
Re: issues with touchpad after update
On Thu, Dec 06, 2018 at 07:52:52AM +1030, Brett Lymn wrote: > I think Martin said he was going to look at this - again, I only have a > clickpad on my laptop so it is hard to test. Yes. > > I think it is just a software feature, maybe not even convenient - I am > > not accustomed to it because e.g. ThinkPads do not have it. > > > > It could be a software feature - if it is then we can do the same sort > of thing I did for emulating 3 buttons on a clickpad (by default that > only reports a left click which is why I started hacking on the driver > in the first place...) It is (or so I think). It just reserves the rightmost n "pixel" (where n should be a sysctl) for the scroll area and translates any slides there into scroll events. The windows driver also offers a horizontal scroll area at the bottom, but those is not marked on the hardware and probably not of much use. The vertical scroll area is optically/harptically marked on my notebook. Martin
