Re: 12.2-RC2 synaptics "tap to click"
On 2020-10-12 13:06, Niclas Zeising wrote: On 2020-10-12 20:49, David wrote: On 2020-10-12 12:08, Niclas Zeising wrote: On 2020-10-12 19:02, David wrote: On 2020-10-12 10:43, Niclas Zeising wrote: On 2020-10-12 17:08, David wrote: On 2020-10-12 08:15, Niclas Zeising wrote: On 2020-10-11 18:55, 2...@gmx.com wrote: On 2020-10-11 09:39, Mark Saad wrote: 2yt Can you provide us some details , what do you have in your boot/loader.conf , etc/sysctl.conf and what do you have in your Xorg config ? /etc/X/11/Xorg.conf does not exist. (auto generate on startup) As far as I know, the only synaptics related setting I have is in /etc/boot.conf hw.psm.synaptics_support="1" This is the default on FreeBSD 12.2. Thank you for letting me know. Attached are the files you requested and the output of sysctl hw.psm On Sun, Oct 11, 2020 at 11:29 AM <2...@gmx.com> wrote: I use a Thinkpad X1 Carbon 4th gen. After upgrading to 12.2 from 12.1, I lost "tap to click" which worked perfectly in past releases. Is this a know feature change? Is there a new sysctl variable that needs set? The other synaptics features are all working just fine. Thanks Can you show what xinput --list-props for the trackpad? (list with xinput --list-devices and then check which device is the trackpad, then xinput --list-props id-of-trackpad). Regards Thank you for the troubleshooting help. The output you requested does show "Tapping Enabled" set to 0. Is this the problem? It could be. You could try just running something like `xinput --set-prop 'SynPS/2 Synaptics TouchPad' 'libinput Tapping Enabled'` and see if it helps. You can use the ID of the device instead of the name, but the ID might change if you for instance boot the machine with an additional keyboard or something. If it works, you can put it in your .xinitrc eor .xsession, and it should take effect every time you start X. Regards Yes, running `xinput --set-prop 10 'libinput Tapping Enabled' 1` did resolve the problem. I will update .xinitrc as a workaround. Question: is this problem unique to my laptop? Are other Thinkpad users not experiencing this issue with 12.2? Thank you so much for helping me. I can't stand the clicking noise the touchpad makes. I don't know if others are experiencing this issue. Myself, I've had the xinput stuff (and some other things) in my .xinitrc for quite some time. Yours is the first report that I've seen about this. Regards In the next day or so I will do a fresh install to confirm whether it is a bug in 12.2 or an update/ssd corruption issue. Will update you with the results. Thanks again for the help! There has been changes in how input devices are handled in FreeBSD xorg. Most of them should have been visible in 12.1 already, but it might be due to this. It is definitely not a bug, it might have been a default that changed with the various updates to xorg and friends, though. Regards Of course you are correct, it is not a bug, rather an undocumented feature change. I did a fresh install of 12.2-RC2 then installed xorg and drm-fbsd12.0-kmod but X wouldn't start. I had to install from ports drm-fbsd12.0-kmod for X to work. The "tap to click" did not work. Perhaps we could update the wiki https://wiki.freebsd.org/SynapticsTouchpad to include the the instructions to enable/disable "tap to click". ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem upgrading from 11.3 to 11.4 (loader init_state not found)
On Thu, 15 Oct 2020 16:10:17 +0200 Patrick Lamaiziere wrote: > Hello, > > We upgraded a virtual machine from 11.3-release-pX to 11.4-release via > freebsd-update. > > Since, the vm does not boot, the loader shows an incomplete menu with > an error : "Options: init_state(heart character) not found" > > I put a photo here : > https://filesender.renater.fr/?s=download&token=e17aa22f-bd1a-48a6-98d2-1aafdb4278ca > > Then if we type "boot" the machine boots properly. > > The menu looks like : > ---Welcome to FreeBSD > 1 <-[-11;6H. <-[-1107;8HYES > > Options: init_state not found > Error while including /boot/menu.rc on the line: menu-display > > Can't load 'kernel' > Type '?' for a list of commands, 'help' for more detailled help > --- > > /boot/loader.conf: > # divers > loader_logo=beastie > loader_color="YES" > > # modules > tcpmd5_load="YES" Well it boots fine if I comment loader_logo and loader_color. But I would love the return of Beastie :-) Regards, ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
problem upgrading from 11.3 to 11.4 (loader init_state not found)
Hello, We upgraded a virtual machine from 11.3-release-pX to 11.4-release via freebsd-update. Since, the vm does not boot, the loader shows an incomplete menu with an error : "Options: init_state(heart character) not found" I put a photo here : https://filesender.renater.fr/?s=download&token=e17aa22f-bd1a-48a6-98d2-1aafdb4278ca Then if we type "boot" the machine boots properly. The menu looks like : ---Welcome to FreeBSD 1 <-[-11;6H. <-[-1107;8HYES Options: init_state not found Error while including /boot/menu.rc on the line: menu-display Can't load 'kernel' Type '?' for a list of commands, 'help' for more detailled help --- /boot/loader.conf: # divers loader_logo=beastie loader_color="YES" # modules tcpmd5_load="YES" I read in /usr/src/UPDATING that there were some changes on the loader but /boot/loader is the same file as /boot/loader.4th so that looks good. Any clue ? Thanks regards. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12.2 cpuset behaves unexpected
After upgrading 11.4 -> 12.2, cpuset now behaves rather different: # cpuset -C -p NNN 11.4: a new set is created with all cpu enabled, and the process is moved into that set, with the thread mask unchanged. 12.2: nothing is done, but an error raises if threadmask == setmask. # cpuset -l XX -C -p NNN 11.4: a new set is created with all cpu enabled, and the process is moved into that set, with the thread mask changed to the -l parameter. 12.2: an error raises if threadmask == setmask, otherwise the threadmask is changed to the -l parameter. It seems the -C option does not work anymore (except for creating errors that appear somehow bogus). PMc ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12.2 Firefox immediate crash "exiting due to channel error"
Hi all, I was forced to upgrade 11.4 -> 12.2, as QT5 reqires openssl 1.1.1. I did a full rebuild from source as of this: 12.2-RC2 FreeBSD 12.2-RC2 #11 r366648M#N1055:1078 (local patches applied - some published via sendbug 10 or 12 years ago) I did a full rebuild of ALL ports from source, as of 2020Q4, Revision: 552058. I verified all files in /usr/local were newly written. Then I removed COMPAT_FREEBSD11. Firefox (firefox-esr 78.3.1_3,1) reproducibly crashes immediate at startup with some "exiting due to channel error". This is solved by putting COMPAT_FREEBSD11 back in (after the better part of a day spent with kernel builds while halving the diffs between GENERIC and mine). I found some comments, but they do not elaborate on the issue, e.g: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233028#c13 (that's two years ago and concerns 12.0-PRERELEASE!) Finally I found this: https://reviews.freebsd.org/D23100 "The Rust ecosystem currently uses pre-ino64 syscalls, so building lang/rust without COMPAT_FREEBSD11 is not going to work." It seems, *RUNNING* rust-built stuff w/o COMPAT11 is also not going to work - and one wouldn't expect this (and probably search for a long time), because removing compat switches finally before rebooting, *AFTER* everything was rebuilt and installation verified, is just good practice. So, as a user I would expect to find this mentioned in some release notes. OTOH, rust is an add-on, and so one could take the position that base is not concerned. But then at least ports/UPDATING should somehow mention it. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"