Re: 12.2-RC2 synaptics "tap to click"

2020-10-15 Thread David

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)

2020-10-15 Thread Patrick Lamaiziere
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=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)

2020-10-15 Thread Patrick Lamaiziere
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=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

2020-10-15 Thread Peter


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"

2020-10-15 Thread Peter


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"