[Note] message initially also sent also to the slint mailing list, resent to this one only with compressed attachments not to be to big to get through. Thanks Gregory for this feed-back. @Tony: I just checked, in Slint's /etc/rc.d/rc.M (attached), we start rc.espeakup (attached) after rc.local and rc.espeakup restores the saved speakup settings. Maybe you saved a speakup setting (using speakup-save) conflicting with the one in rc.local? This would lead to the behavior you observed. Anyway as we only modprobe espeakup in rc.espeakup, I don't think that /sys/accessibility/speakup be writable before that. This seems to be confirmed here: I get this boot message just berore the ones from rc.espeakup: /etc/rc.d/rc.local: line 10: /sys/accessibility/speakup/key_echo: No such file or directory If my assumptions are correct, don't use rc.local for this kind of setting, use speakup-save instead, and this is not related to the kernel upgrade. Best regards, Didier Le 09/09/2020 à 07:50, Gregory Nowak a écrit : > For what it's worth, I'm running a self compiled 5.4.63 kernel on a > devuan 2.1 system. I added the line: > > echo 0 > /sys/accessibility/speakup/key_echo > > to my /etc/rc.local above the last "exit 0" line, and rebooted. After > reboot, I wasn't able to hear characters I typed from speakup, which > was expected. > > Greg > > > On Tue, Sep 08, 2020 at 10:54:33AM +0200, Didier Spaier wrote: >> Hi Tony, >> >> CCing this answer to the speakup mailing list. >> >> @speakup list: the report is after upgrading a kernel from 4.19.67 to 5.4.62. >> Did anyone observed a similar behavior? >> >> The issue with the line in rc.local ineffective at boot time is indeed weird. >> >> This file is executed at the very end of the booting sequence, so I pretty >> much doubt that sysfs be not yet available. >> >> To check I did this (an you can do it too): >> I inserted the following line in /etc/rc.d/rc.local: >> echo "the command run by rc.local should be executed now." > /dev/kmsg >> then made executable rc.local typing "chmod 755 /etc/rc.d/rc.local" >> >> Then after a reboot I typed as root: >> dmesg|grep rc.local >> The output was: >> [ 17.128784] the command run by rc.local should be executed now. >> >> So your command would have been executed 17 seconds after booting. >> >> Incidentally, instead of including the echo command in rc.local you could, once >> your speakup settings are done to your liking, just type as root: >> speakup-save >> >> Then these settings should be restored after next boot. >> >> They are stored independently for each hard synthesizer and the soft one. >> >> Does this work for you? >> >> Cheers, >> Didier >> >> Le 08/09/2020 à 02:08, tony seth a écrit : >>> Heya there and good evening! >>> Well, ya told me to install the kernel and see what breaks, and I did. >>> The kernel upgrade went fine, and all seems fine, except for a tiny but important thing. >>> I have an /etc/rc.d/rc.local file which turns off echoing of characters typed in the console when I use Speakup. >>> The line in the file is this: >>> echo 0 > /sys/accessibility/speakup/key_echo >>> >>> Up until the upgrade this worked just fine, but afterward, it doesn't. Characters are echoed again, unless I run as root: >>> /etc/rc.d/rc.local >>> This fixes the problem until next reboot. >>> Just curious how I could fix this, or is it that the sysfs isn't being created early enough for the rc.local file to work on the key_echo entry? >>> Thanks much as always though, other then that I've not had any problems, and the braille display works fine as well. >>> I bring that up because you mentioned Phillip having the braille display problem. >>> I'm using an Inceptor Braille Me in usb mode. >>> Thanks again... >>> Take care... Cheereo! >>> >> >> _______________________________________________ >> Speakup mailing list >> Speakup@xxxxxxxxxxxxxxxxx >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
