Re: Audio recording (using ossaudio)
At Sat, 14 Mar 2020 15:05:37 +0200, Yorick Hardy wrote: > Re: audacity (earlier in the thread), audacity hangs whenever I try to > record. Would you tell how to reproduce it? Thanks, --- Tetsuya Isaki
Re: Audio recording (using ossaudio)
At Tue, 10 Mar 2020 20:49:55 +0200, Yorick Hardy wrote: > ffmpeg4 -f oss -i /dev/audio -channels 1 -sample_rate 48000 /tmp/test.wav > > is completely garbled and too short. The file also seems to be 2-channel, > so I think the recording settings are somehow not applied correctly. I rarely use ffmpeg4 but according to ffmpeg4 documents, -channels/-sample_rate are for video and -ac/-ar are for audio? % /usr/bin/time ffmpeg4 -f oss -t 0:05 -i /dev/audio -channels 1 test1.wav 5.04 real 0.02 user 0.04 sys % file test1.wav test1.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz % /usr/bin/time ffmpeg4 -f oss -t 0:05 -i /dev/audio -ac 1 test2.wav 5.04 real 0.04 user 0.02 sys % file test2.wav test2.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz % /usr/bin/time audioplay test1.wav 2.54 real 0.00 user 0.00 sys % /usr/bin/time audioplay test2.wav 2.54 real 0.00 user 0.00 sys As you said, output file was too short. However ffmpeg4 probably recorded specified period and created small file so that I think you need to look ffmpeg4 at first. Thanks, --- Tetsuya Isaki
Re: firefox-74.0 crash on -current
На 2020-03-18 в 04:01, Ryo ONODERA написа: > Hi, > > Your firefox-73.0.1 and 74.0 share the same graphics/MesaLib? > And what is your GPU? > > With my Intel internal GPU in KabyLake Refresh, > https://webglsamples.org/aquarium/aquarium.html > works fine (firefox-74.0/MesaLib-20.0.1nb1). It still crashes for me on real hardware, but I see your MesaLib is newer, so I am going to update it as well. I usually do the updates the long way via pkg_rolling-replace, this time was lazy and updated only firefox, rust and cbindgen before building firefox, so most likely it is my fault. > Thank you. > > Chavdar Ivanov writes: > >> Hi, >> >> On today's -current my build of firefox-74.0 (from yesterday, rust >> 1.42.0 from the day before, cbindgen also rebuilt), when I access the >> demos at webglsamples.org I get: >> >> Core was generated by `firefox'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 >> [Current thread is 1 (process 1)] >> (gdb) bt >> #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 >> #1 0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so >> #2 0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so >> #3 0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12 >> #4 0x0001000b in ?? () >> #5 0x in ?? () >> ... >> >> On the same system, firefox-73.0.1 works just fine. >> >> >> Chavdar >> >> >> -- >>
Re: Automated report: NetBSD-current/i386 test failure
Probably mine - working on it On Wed, 18 Mar 2020, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: dev/sysmon/t_swsensor:alarm_sensor dev/sysmon/t_swsensor:entropy_interrupt_sensor dev/sysmon/t_swsensor:entropy_polled_sensor dev/sysmon/t_swsensor:limit_sensor dev/sysmon/t_swsensor:simple_sensor The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.03.16.20.07.44 ad src/sys/uvm/pmap/pmap_pvt.c,v 1.10 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/if_xennet_xenbus.c,v 1.89 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/xennet_checksum.c,v 1.5 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.77 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/include/xennet_checksum.h,v 1.2 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/if_xennet_xenbus.c,v 1.90 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/xennet_checksum.c,v 1.6 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.78 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_mod.c,v 1.12 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_sysctl.c,v 1.45 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_sysctl.h,v 1.7 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_mod.c,v 1.13 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_sysctl.c,v 1.18 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_sysctl.h,v 1.5 2020.03.16.21.20.09 pgoyette src/sys/dev/acpi/acpi_cpu.c,v 1.52 2020.03.16.21.20.09 pgoyette src/sys/dev/pci/ubsec.c,v 1.48 2020.03.16.21.20.09 pgoyette src/sys/dev/sysmon/swsensor.c,v 1.16 2020.03.16.21.20.09 pgoyette src/sys/dev/sysmon/swwdog.c,v 1.22 2020.03.16.21.20.09 pgoyette src/sys/fs/adosfs/advfsops.c,v 1.79 2020.03.16.21.20.09 pgoyette src/sys/fs/autofs/autofs_vfsops.c,v 1.10 2020.03.16.21.20.09 pgoyette src/sys/fs/cd9660/cd9660_vfsops.c,v 1.95 2020.03.16.21.20.10 pgoyette src/sys/fs/filecorefs/filecore_vfsops.c,v 1.83 2020.03.16.21.20.10 pgoyette src/sys/fs/msdosfs/msdosfs_vfsops.c,v 1.133 2020.03.16.21.20.10 pgoyette src/sys/fs/nilfs/nilfs_vfsops.c,v 1.26 2020.03.16.21.20.10 pgoyette src/sys/fs/ptyfs/ptyfs_vfsops.c,v 1.58 2020.03.16.21.20.10 pgoyette src/sys/fs/smbfs/smbfs_vfsops.c,v 1.109 2020.03.16.21.20.10 pgoyette src/sys/fs/udf/udf_vfsops.c,v 1.78 2020.03.16.21.20.10 pgoyette src/sys/fs/union/union_vfsops.c,v 1.81 2020.03.16.21.20.10 pgoyette src/sys/kern/sys_aio.c,v 1.47 2020.03.16.21.20.10 pgoyette src/sys/kern/sys_mqueue.c,v 1.46 2020.03.16.21.20.10 pgoyette src/sys/kern/vfs_wapbl.c,v 1.106 2020.03.16.21.20.11 pgoyette src/sys/miscfs/fdesc/fdesc_vfsops.c,v 1.94 2020.03.16.21.20.11 pgoyette src/sys/miscfs/kernfs/kernfs_vfsops.c,v 1.99 2020.03.16.21.20.11 pgoyette src/sys/miscfs/nullfs/null_vfsops.c,v 1.97 2020.03.16.21.20.11 pgoyette src/sys/miscfs/overlay/overlay_vfsops.c,v 1.69 2020.03.16.21.20.11 pgoyette src/sys/miscfs/procfs/procfs_vfsops.c,v 1.103 2020.03.16.21.20.11 pgoyette src/sys/miscfs/umapfs/umap_vfsops.c,v 1.102 2020.03.16.21.20.11 pgoyette src/sys/net/bpf.c,v 1.236 2020.03.16.21.20.11 pgoyette src/sys/netinet/accf_http.c,v 1.10 2020.03.16.21.20.11 pgoyette src/sys/nfs/nfs_vfsops.c,v 1.240 2020.03.16.21.20.12 pgoyette src/sys/opencrypto/crypto.c,v 1.113 2020.03.16.21.20.12 pgoyette src/sys/secmodel/bsd44/bsd44.h,v 1.7 2020.03.16.21.20.12 pgoyette src/sys/secmodel/bsd44/secmodel_bsd44.c,v 1.17 2020.03.16.21.20.12 pgoyette src/sys/secmodel/extensions/secmodel_extensions.c,v 1.12 2020.03.16.21.20.12 pgoyette src/sys/secmodel/overlay/secmodel_overlay.c,v 1.14 2020.03.16.21.20.12 pgoyette src/sys/secmodel/securelevel/secmodel_securelevel.c,v 1.34 2020.03.16.21.20.12 pgoyette src/sys/secmodel/securelevel/securelevel.h,v 1.5 2020.03.16.21.20.12 pgoyette src/sys/secmodel/suser/secmodel_suser.c,v 1.52 2020.03.16.21.20.12 pgoyette src/sys/secmodel/suser/suser.h,v 1.3 2020.03.16.21.20.12 pgoyette src/sys/ufs/ext2fs/ext2fs_vfsops.c,v 1.217 2020.03.16.21.20.12 pgoyette src/sys/ufs/ffs/ffs_vfsops.c,v 1.366 2020.03.16.21.20.13 pgoyette src/sys/ufs/lfs/lfs_vfsops.c,v 1.377 2020.03.16.21.20.13 pgoyette src/sys/ufs/mfs/mfs_vfsops.c,v 1.114 2020.03.16.21.20.13 pgoyette src/sys/ufs/ufs/ufs_dirhash.c,v 1.40 2020.03.16.22.02.37 macallan src/sys/arch/powerpc/oea/ofw_rascons.c,v 1.14 2020.03.16.22.02.37 macallan src/sys/arch/powerpc/oea/ofw_rasconsvar.h,v 1.3 2020.03.17.00.30.17 ad src/sys/uvm/uvm_page_array.c,v 1.5 2020.03.17.00.50.12 fox src/external/cddl/osnet/lib/libdtrace/Makefile,v 1.27 2020.03.17.00.54.03 fox
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: dev/sysmon/t_swsensor:alarm_sensor dev/sysmon/t_swsensor:entropy_interrupt_sensor dev/sysmon/t_swsensor:entropy_polled_sensor dev/sysmon/t_swsensor:limit_sensor dev/sysmon/t_swsensor:simple_sensor The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.03.16.20.07.44 ad src/sys/uvm/pmap/pmap_pvt.c,v 1.10 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/if_xennet_xenbus.c,v 1.89 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/xennet_checksum.c,v 1.5 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.77 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/include/xennet_checksum.h,v 1.2 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/if_xennet_xenbus.c,v 1.90 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/xennet_checksum.c,v 1.6 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.78 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_mod.c,v 1.12 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_sysctl.c,v 1.45 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_sysctl.h,v 1.7 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_mod.c,v 1.13 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_sysctl.c,v 1.18 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_sysctl.h,v 1.5 2020.03.16.21.20.09 pgoyette src/sys/dev/acpi/acpi_cpu.c,v 1.52 2020.03.16.21.20.09 pgoyette src/sys/dev/pci/ubsec.c,v 1.48 2020.03.16.21.20.09 pgoyette src/sys/dev/sysmon/swsensor.c,v 1.16 2020.03.16.21.20.09 pgoyette src/sys/dev/sysmon/swwdog.c,v 1.22 2020.03.16.21.20.09 pgoyette src/sys/fs/adosfs/advfsops.c,v 1.79 2020.03.16.21.20.09 pgoyette src/sys/fs/autofs/autofs_vfsops.c,v 1.10 2020.03.16.21.20.09 pgoyette src/sys/fs/cd9660/cd9660_vfsops.c,v 1.95 2020.03.16.21.20.10 pgoyette src/sys/fs/filecorefs/filecore_vfsops.c,v 1.83 2020.03.16.21.20.10 pgoyette src/sys/fs/msdosfs/msdosfs_vfsops.c,v 1.133 2020.03.16.21.20.10 pgoyette src/sys/fs/nilfs/nilfs_vfsops.c,v 1.26 2020.03.16.21.20.10 pgoyette src/sys/fs/ptyfs/ptyfs_vfsops.c,v 1.58 2020.03.16.21.20.10 pgoyette src/sys/fs/smbfs/smbfs_vfsops.c,v 1.109 2020.03.16.21.20.10 pgoyette src/sys/fs/udf/udf_vfsops.c,v 1.78 2020.03.16.21.20.10 pgoyette src/sys/fs/union/union_vfsops.c,v 1.81 2020.03.16.21.20.10 pgoyette src/sys/kern/sys_aio.c,v 1.47 2020.03.16.21.20.10 pgoyette src/sys/kern/sys_mqueue.c,v 1.46 2020.03.16.21.20.10 pgoyette src/sys/kern/vfs_wapbl.c,v 1.106 2020.03.16.21.20.11 pgoyette src/sys/miscfs/fdesc/fdesc_vfsops.c,v 1.94 2020.03.16.21.20.11 pgoyette src/sys/miscfs/kernfs/kernfs_vfsops.c,v 1.99 2020.03.16.21.20.11 pgoyette src/sys/miscfs/nullfs/null_vfsops.c,v 1.97 2020.03.16.21.20.11 pgoyette src/sys/miscfs/overlay/overlay_vfsops.c,v 1.69 2020.03.16.21.20.11 pgoyette src/sys/miscfs/procfs/procfs_vfsops.c,v 1.103 2020.03.16.21.20.11 pgoyette src/sys/miscfs/umapfs/umap_vfsops.c,v 1.102 2020.03.16.21.20.11 pgoyette src/sys/net/bpf.c,v 1.236 2020.03.16.21.20.11 pgoyette src/sys/netinet/accf_http.c,v 1.10 2020.03.16.21.20.11 pgoyette src/sys/nfs/nfs_vfsops.c,v 1.240 2020.03.16.21.20.12 pgoyette src/sys/opencrypto/crypto.c,v 1.113 2020.03.16.21.20.12 pgoyette src/sys/secmodel/bsd44/bsd44.h,v 1.7 2020.03.16.21.20.12 pgoyette src/sys/secmodel/bsd44/secmodel_bsd44.c,v 1.17 2020.03.16.21.20.12 pgoyette src/sys/secmodel/extensions/secmodel_extensions.c,v 1.12 2020.03.16.21.20.12 pgoyette src/sys/secmodel/overlay/secmodel_overlay.c,v 1.14 2020.03.16.21.20.12 pgoyette src/sys/secmodel/securelevel/secmodel_securelevel.c,v 1.34 2020.03.16.21.20.12 pgoyette src/sys/secmodel/securelevel/securelevel.h,v 1.5 2020.03.16.21.20.12 pgoyette src/sys/secmodel/suser/secmodel_suser.c,v 1.52 2020.03.16.21.20.12 pgoyette src/sys/secmodel/suser/suser.h,v 1.3 2020.03.16.21.20.12 pgoyette src/sys/ufs/ext2fs/ext2fs_vfsops.c,v 1.217 2020.03.16.21.20.12 pgoyette src/sys/ufs/ffs/ffs_vfsops.c,v 1.366 2020.03.16.21.20.13 pgoyette src/sys/ufs/lfs/lfs_vfsops.c,v 1.377 2020.03.16.21.20.13 pgoyette src/sys/ufs/mfs/mfs_vfsops.c,v 1.114 2020.03.16.21.20.13 pgoyette src/sys/ufs/ufs/ufs_dirhash.c,v 1.40 2020.03.16.22.02.37 macallan src/sys/arch/powerpc/oea/ofw_rascons.c,v 1.14 2020.03.16.22.02.37 macallan src/sys/arch/powerpc/oea/ofw_rasconsvar.h,v 1.3 2020.03.17.00.30.17 ad src/sys/uvm/uvm_page_array.c,v 1.5 2020.03.17.00.50.12 fox src/external/cddl/osnet/lib/libdtrace/Makefile,v 1.27 2020.03.17.00.54.03 fox src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_acl.c,v 1.6
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2020.03.18.09.42.05 martin src/sys/dev/usb/if_aue.c,v 1.170 2020.03.18.10.05.24 nisimura src/sys/arch/arm/sociox/sni_emmc.c,v 1.3 2020.03.18.10.56.38 jmcneill src/sys/arch/evbarm/conf/GENERIC64,v 1.146 2020.03.18.11.33.32 kre src/sys/dev/usb/if_aue.c,v 1.171 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.03.html#2020.03.18.11.33.32
Re: firefox-74.0 crash on -current
On Wed, 18 Mar 2020 at 04:01, Ryo ONODERA wrote: > > Hi, > > Your firefox-73.0.1 and 74.0 share the same graphics/MesaLib? It is on the same machine, so I would presume so. How should I check? MesaLib does not appear as a dependency. The version installed is MesaLib-19.2.7nb4. > And what is your GPU? In this case the test was done under VirtualBox: ... [40.370] (II) Initializing extension GLX [40.371] (II) AIGLX: Screen 0 is not DRI2 capable [40.955] (II) IGLX: Loaded and initialized swrast [40.955] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [40.956] (II) Initializing extension XFree86-VidModeExtension [40.956] (II) Initializing extension XFree86-DGA [40.957] (II) Initializing extension XFree86-DRI [40.957] (II) Initializing extension DRI2 and 73.0.1 works fine. If I upgrade it to 74.0 - using pkgin - it crashes when opening a WebGL demo; otherwise it works fine. > > With my Intel internal GPU in KabyLake Refresh, > https://webglsamples.org/aquarium/aquarium.html > works fine (firefox-74.0/MesaLib-20.0.1nb1). I still haven't tested my laptop (Intel 530 grapics) yet, I might boot NetBSD later for that. > > Thank you. Thanks, Chavdar > > Chavdar Ivanov writes: > > > Hi, > > > > On today's -current my build of firefox-74.0 (from yesterday, rust > > 1.42.0 from the day before, cbindgen also rebuilt), when I access the > > demos at webglsamples.org I get: > > > > Core was generated by `firefox'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 > > [Current thread is 1 (process 1)] > > (gdb) bt > > #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 > > #1 0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so > > #2 0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so > > #3 0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12 > > #4 0x0001000b in ?? () > > #5 0x in ?? () > > ... > > > > On the same system, firefox-73.0.1 works just fine. > > > > > > Chavdar > > > > > > -- > > > > -- > Ryo ONODERA // r...@tetera.org > PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 --
Re: pmap panic
On Tue, 17 Mar 2020 23:36:23 + Andrew Doran wrote: > Ok. I think the problems here should be fixed. > > Andrew Hi, I confirm my bare metal desktop system is stable now. It does feel much snappier than before so the pain was worth it in the end. :) On my VirtualBox machine I have a feeling that it is spending more time doing TLB shootdowns than before on /some/ workloads. Running cvs update on a cgd(4) is definitely slower than before. Randomly breaking into ddb shows that it's always spinning in pmap_tlb_shootnow() rather than waiting for disk or net I/O which I would expect. I couldn't reproduce the problem on bare metal so it might just be the usual VirtualBox jank. -Tobias
Re: Two finger scrolling
On Wed, Mar 18, 2020 at 12:55:27PM +0900, Ryo ONODERA wrote: > Hi, > > Can I add sysctl node to disable two finger scroll as follows? > > And > https://mail-index.netbsd.org/source-changes/2020/03/14/msg115107.html > is essential for my Synaptics 8.16 TouchPad in HP Sectre x360 13-inch > year 2017 model (ae019TU). > If it is removed, I cannot perform any drag-and-drop with two fingers. > My patch also adds this part if two finger scroll is disabled. We should probably fix the driver or temporarily revert so that gestures still work by default. I'm not sure why gestures are broken for me.
Re: Ethernet / Wifi driver locking changes: if_aue.c
On Wed, Mar 18, 2020 at 02:59:18AM -, Christos Zoulas wrote: > In article <25369.1584454...@jinx.noi.kre.to>, > Robert Elz wrote: > >I'd suggest the following change to deal with the undefined "un" > >variable that appears when USB_DEBUG is defined (the var was deleted > >in the changes - other uses went away). > > > >I'm not committing this as I am not in a position to even compile > >test it (let alone verify that it is correct). > > Thanks, committed something similar. Needs a bit extra - prefer #ifdef USB_DEBUG, or __used ? Cheers, Patrick
Re: Two finger scrolling
On Wed, Mar 18, 2020 at 12:17:23PM +1030, Brett Lymn wrote: > OK, IIRC whether or not you get the click pad button emulation depends > on how the device reports itself - they are only there for one-button > click pads. pms0: Extended W mode, Passthrough, Up/down buttons, Palm detect, One button click pad, Multi-finger Report, Multi-finger > My main concern here is that you have converted all multi-touch into a > scroll event. I probably did, but I can't test other multitouch events :/ > What W values were you getting when testing the two finger scroll? Do > you have a copy of the "Synaptics PS/2 TouchPad Interfacting Guide, PN: > 511-000275-01 Rev. B"? I haven't located a later document but this one > does describe the various modes and what W means in those modes because, > unfortunately, it is overloaded depending on the mode the device is in. > I can send you a pdf of the document off list if you don't already have > a copy. I recall finger_scroll-min=7 generating wrong scroll events, and finger_scroll-min=8 generating no events. I'd really appreciate the PDF. > Is it an actual synaptics touchpad on the end of I2C? I vaguely recall > that there is an ability to connect via I2C but I may be > mis-remembering. It's likely. Unfortunately this pad also needs fixing, the button is physically disconnected...
Re: Two finger scrolling
On Tue, Mar 17, 2020 at 18:48 Brett Lymn wrote: > On Tue, Mar 17, 2020 at 11:04:46AM +, nia wrote: > > > > "Newer" thinkpads (x250, 2015...) have single-button clickpads with extra > > wired buttons. Until a few revisions ago these buttons couldn't be > configured > > to act as regular mouse buttons and defaulted to acting as buttons 4 and > 5. > > It’s certainly my curses/terminfo experience coming into play, but is there a case for making a mousecap/mouseinfo facility to take this, or is that not a proper characterization of the problem? -bch > > That is good... > > > I haven't managed to get right clicks with the clickpad to work either, > > honestly. I was not sure how this was supposed to work until you > explained > > it. To clarify, clicking the pad down with a single finger in the right > > area of the pad rarely results in a right click menu either. I worked > > around this by adding a knob to recognize the extra buttons as regular > > mouse buttons by default. > > > > OK, IIRC whether or not you get the click pad button emulation depends > on how the device reports itself - they are only there for one-button > click pads. > > My main concern here is that you have converted all multi-touch into a > scroll event. > > What W values were you getting when testing the two finger scroll? Do > you have a copy of the "Synaptics PS/2 TouchPad Interfacting Guide, PN: > 511-000275-01 Rev. B"? I haven't located a later document but this one > does describe the various modes and what W means in those modes because, > unfortunately, it is overloaded depending on the mode the device is in. > I can send you a pdf of the document off list if you don't already have > a copy. > > > I've got another laptop with a single button clickpad, and no buttons, > > but that's using the ims(4) driver which is significantly less useful. > > > > Is it an actual synaptics touchpad on the end of I2C? I vaguely recall > that there is an ability to connect via I2C but I may be > mis-remembering. > > > > > The number of sysctl parameters with fairly magical values makes > configuring > > this driver to a usable state a quite confusing affair. But yeah, the > > values are not fine-grained enough for me for that particular knob. > > Yes, it is unfortunate that there are a lot of magical parameters there. > Hopefully most of them have sensible defaults, some are configured based > on reports from the trackpad itself but are exposed because sometimes > the trackpads lie. > > Given what you are saying I am wondering if your trackpad was actually > in extended-W mode or not. The W value, like a lot of the registers in > the trackpad, is overloaded and the numbers can mean different things > depending on what mode the trackpad is in and, even worse, the trackpad > won't tell you what mode it is in so you can't just test this. > > -- > Brett Lymn > -- > Sent from my NetBSD device. > > "We are were wolves", > "You mean werewolves?", > "No we were wolves, now we are something else entirely", > "Oh" >
Re: Two finger scrolling
On Tue, Mar 17, 2020 at 19:08 bch wrote: > > > On Tue, Mar 17, 2020 at 18:48 Brett Lymn wrote: > >> On Tue, Mar 17, 2020 at 11:04:46AM +, nia wrote: >> > >> > "Newer" thinkpads (x250, 2015...) have single-button clickpads with >> extra >> > wired buttons. Until a few revisions ago these buttons couldn't be >> configured >> > to act as regular mouse buttons and defaulted to acting as buttons 4 >> and 5. >> > > > > It’s certainly my curses/terminfo experience coming into play, but is > there a case for making a mousecap/mouseinfo facility to take > *facility to TAME this... this, or is that not a proper characterization of the problem? > > -bch > > > >> >> That is good... >> >> > I haven't managed to get right clicks with the clickpad to work either, >> > honestly. I was not sure how this was supposed to work until you >> explained >> > it. To clarify, clicking the pad down with a single finger in the right >> > area of the pad rarely results in a right click menu either. I worked >> > around this by adding a knob to recognize the extra buttons as regular >> > mouse buttons by default. >> > >> >> OK, IIRC whether or not you get the click pad button emulation depends >> on how the device reports itself - they are only there for one-button >> click pads. >> >> My main concern here is that you have converted all multi-touch into a >> scroll event. >> >> What W values were you getting when testing the two finger scroll? Do >> you have a copy of the "Synaptics PS/2 TouchPad Interfacting Guide, PN: >> 511-000275-01 Rev. B"? I haven't located a later document but this one >> does describe the various modes and what W means in those modes because, >> unfortunately, it is overloaded depending on the mode the device is in. >> I can send you a pdf of the document off list if you don't already have >> a copy. >> >> > I've got another laptop with a single button clickpad, and no buttons, >> > but that's using the ims(4) driver which is significantly less useful. >> > >> >> Is it an actual synaptics touchpad on the end of I2C? I vaguely recall >> that there is an ability to connect via I2C but I may be >> mis-remembering. >> >> > >> > The number of sysctl parameters with fairly magical values makes >> configuring >> > this driver to a usable state a quite confusing affair. But yeah, the >> > values are not fine-grained enough for me for that particular knob. >> >> Yes, it is unfortunate that there are a lot of magical parameters there. >> Hopefully most of them have sensible defaults, some are configured based >> on reports from the trackpad itself but are exposed because sometimes >> the trackpads lie. >> >> Given what you are saying I am wondering if your trackpad was actually >> in extended-W mode or not. The W value, like a lot of the registers in >> the trackpad, is overloaded and the numbers can mean different things >> depending on what mode the trackpad is in and, even worse, the trackpad >> won't tell you what mode it is in so you can't just test this. >> >> -- >> Brett Lymn >> -- >> Sent from my NetBSD device. >> >> "We are were wolves", >> "You mean werewolves?", >> "No we were wolves, now we are something else entirely", >> "Oh" >> >
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2020.03.18.04.02.20. An extract from the build.sh output follows: --- dependall-unvis --- --- dependall-usr.sbin --- #format timed/timed.ps --- dependall-usr.bin --- --- unvis.o --- --- dependall-sys --- --- ip.o --- --- dependall-usr.sbin --- GROFF_ENCODING= GROFF_BIN_PATH=/tmp/bracket/build/2020.03.18.04.02.20-i386/tools/lib/groff GROFF_FONT_PATH=/tmp/bracket/build/2020.03.18.04.02.20-i386/tools/share/groff/site-font:/tmp/bracket/build/2020.03.18.04.02.20-i386/tools/share/groff/font GROFF_TMAC_PATH=/tmp/bracket/build/2020.03.18.04.02.20-i386/tools/share/groff/site-tmac:/tmp/bracket/build/2020.03.18.04.02.20-i386/tools/share/groff/tmac /tmp/bracket/build/2020.03.18.04.02.20-i386/tools/bin/nbgroff -Tps -t -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/usr.sbin/timed/SMM.doc/timed -ms /tmp/bracket/build/2020.03.18.04.02.20-i386/src/usr.sbin/timed/SMM.doc/timed/timed.ms | /tmp/bracket/build/2020.03.18.04.02.20-i386/tools/bin/nbsed -e '/^%%CreationDate:/d' > timed.ps --- dependall-sys --- # compile sa/ip.o --- dependall-usr.bin --- # compile unvis/unvis.o --- dependall-sys --- /tmp/bracket/build/2020.03.18.04.02.20-i386/tools/bin/i486--netbsdelf-gcc -Wall -Wmissing-prototypes -Wstrict-prototypes -Os -ffreestanding -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-exceptions -mno-sse -std=gnu99 -Werror -march=i386 -mtune=i386 -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libsa --sysroot=/tmp/bracket/build/2020.03.18.04.02.20-i386/destdir -DBOOTXX -I /tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../lib -I /tmp/bracket/build/2020.03.18.04.02.20-i386/obj/sys/arch/i386/stand/bootxx/bootxx_ext2fs -DBOOTXX_SECTORS=15 -DPRIMARY_LOAD_ADDRESS=0x1000 -DSECONDARY_LOAD_ADDRESS=0x1 -DXXfs_open=ext2fs_open -DXXfs_close=ext2fs_close -DXXfs_read=ext2fs_read -DXXfs_stat=ext2fs_stat -DFS=ext2fs -DNO_LBA_CHECK -DEPIA_HACK -nostdinc -D_STANDALONE -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/boo txx_ext2fs/../../../../.. -DLI--- dependall-usr.bin --- /tmp/bracket/build/2020.03.18.04.02.20-i386/tools/bin/i486--netbsdelf-gcc -O2 -fPIE-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/tmp/bracket/build/2020.03.18.04.02.20-i386/destdir -c /tmp/bracket/build/2020.03.18.04.02.20-i386/src/usr.bin/unvis/unvis.c --- dependall-sys --- BSA_SINGLE_FILESYSTEM=xxfs -DLIBSA_NO_TWIDDLE -DLIBSA_NO_FD_CHECKING -DLIBSA_NO_RAW_ACCESS -DLIBSA_NO_FS_WRITE -DLIBSA_NO_FS_SEEK -DLIBSA_SINGLE_DEVICE=blkdev -DLIBKERN_OPTIMISE_SPACE -D"blkdevioctl(x,y,z)=EINVAL" -D"blkdevclose(f)=0" -D"devopen(f,n,fl)=(*(fl)=(void *)n,0)" -DLIBSA_NO_DISKLABEL_MSGS -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/quad -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/string -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libkern/../../../common/lib/libc/arch/i386/string -I/tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/arch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libsa/../../../common/dist/zlib -DCOMPAT_UFS -Wno-pointer-sign -c /tmp/bracket/build/2020.03.18.04.02.20-i386/src/sys/a rch/i386/stand/bootxx/bootxx_ext2fs/../../../../../lib/libsa/ip.c -o ip.o --- dependall-modules --- cc1: all warnings being treated as errors *** [if_aue.o] Error code 1 --- dependall-usr.sbin --- --- dependall-sysinst --- The following commits were made between the last successful build and the failed build: 2020.03.18.02.21.24 nisimura src/sys/arch/evbarm/conf/GENERIC64,v 1.143 2020.03.18.02.36.53 nisimura src/sys/arch/arm/sociox/files.sociox,v 1.5 2020.03.18.02.58.24 christos src/sys/dev/usb/if_aue.c,v 1.169 2020.03.18.03.26.14 nisimura src/sys/arch/evbarm/conf/GENERIC64,v 1.144 2020.03.18.03.33.49 nisimura src/sys/arch/arm/sociox/sni_emmc.c,v 1.1 2020.03.18.03.33.49 nisimura src/sys/arch/arm/sociox/sni_i2c.c,v 1.1 2020.03.18.03.49.17 nisimura src/sys/arch/arm/sociox/files.sociox,v 1.6 2020.03.18.04.02.20 nisimura src/sys/arch/evbarm/conf/GENERIC64,v 1.145 Log files can
