Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #243558 > unrolled thread

Re: Hyper-typematic and Firefox responsiveness in Weston.

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Hyper-typematic and Firefox responsiveness in Weston. Johann Klammer <klammerj@a1.net> - 2021-12-31 19:50 +0100
    Re: Hyper-typematic and Firefox responsiveness in Weston. <tomas@tuxteam.de> - 2022-01-01 08:00 +0100
    Re: Hyper-typematic and Firefox responsiveness in Weston. peter@easthope.ca - 2022-01-01 20:40 +0100
      Re: Hyper-typematic and Firefox responsiveness in Weston. David Wright <deblis@lionunicorn.co.uk> - 2022-01-03 04:10 +0100
        Re: Hyper-typematic and Firefox responsiveness in Weston. David <bouncingcats@gmail.com> - 2022-01-03 06:30 +0100
          Re: Hyper-typematic and Firefox responsiveness in Weston. David Wright <deblis@lionunicorn.co.uk> - 2022-01-03 22:50 +0100
            Re: Hyper-typematic and Firefox responsiveness in Weston. David <bouncingcats@gmail.com> - 2022-01-04 04:50 +0100
              Re: Hyper-typematic and Firefox responsiveness in Weston. David <bouncingcats@gmail.com> - 2022-01-04 05:30 +0100
        Re: Hyper-typematic and Firefox responsiveness in Weston. peter@easthope.ca - 2022-01-18 06:10 +0100

#243558 — Re: Hyper-typematic and Firefox responsiveness in Weston.

On 12/31/2021 05:10 AM, peter@easthope.ca wrote:
> Hi,
> 
> Debian 11 is easily arranged so that "startx" or "weston" can be 
> issued at the console command line.  That allows simple qualitative 
> comparisons.
> 
> In weston, keyboard response can be hyper-typematic.  The briefest 
> keypress can give at least two instances of the key action; sometimes a 
> half dozen.  That includes backspace.  Consequently keyboard input is 
> impossible. This happens not in every instance of weston but often 
> enough to be a nuisance. Has anyone else observed this?
> 
> According to documentation, Firefox works natively in Weston.  Ie. 
> Firefox doesn't work through Xwayland. With Wayland intended to be 
> more efficient than X11 I expect Firefox to be more responsive on 
> Weston than on X11.  Nevertheless Firefox is noticeably slower on 
> Weston. Anyone else observed this?
> 
> Thanks & best regards,             ... P.
> 
> 
> 
> 
Haven't you noticed the x.org people fucking stuff up since Xfree became x.org?
Why do you expect this to chsange?

[toc] | [next] | [standalone]

#243567

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 31, 2021 at 07:15:53PM +0100, Johann Klammer wrote:

[...]

> Haven't you noticed the x.org people fucking stuff up since Xfree became x.org?
> Why do you expect this to chsange?

Try to be more constructive next time. You can do, promised!

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#243573

    From: Johann Klammer <klammerj@a1.net>
    Date: Fri, 31 Dec 2021 19:15:53 +0100
> Haven't you noticed the x.org people f***ing stuff up since Xfree 
> became x.org?

The two problems I described and the following are serious impairments 
of the system.  A convincing explanation can help to solve a problem 
but I have yet to find an explanation in these cases.  

Spontaneously, windows in the display vanish.  =8~(  If a toolbar is 
present at the bottom of the display, it remains.  A mouse click on 
the toolbar restores the vanished windows.  =8~)  Appears that mouse 
activity triggers vanishing.  Happens once per hour or two.  
Infrequently enough to tolerate but definitely a nuisance.  When 
OpenBox is used without a toolbar, the only way I have to restore the 
display is close OpenBox and open anew.  =8~(

> Why do you expect this to chsange?

I don't particularly expect progress but without progress Debian will 
become an obsolete curiosity.  As have Atari ST and Amiga. 
https://en.wikipedia.org/wiki/Atari_ST
https://en.wikipedia.org/wiki/Amiga
A few dedicated hobbyists use them.  They are not general purpose 
workstations.

Incidentally, with a little dedication and skill Atari and Amiga 
handle email.  That's textual email.  A MUA doesn't have to be a video 
player.  A boot loader doesn't have to be an operating system.

For progress to occur, maintainers need to acknowledge problems 
honestly and address honestly.  "Try testing." and "Does the problem 
remain in the new stable release?" might help; they aren't solutions.

Too much icing on top of a cake will make it fall over.  =8~(  Better 
to remove some icing and focus on the lower layers of cake.  =8~)
https://en.wikipedia.org/wiki/Wedding_cake

Johann, the tone of your question suggests (to me at least) that you 
don't expect a Debian system to be a general purpose workstation.
Is the Linux workstation obsolete?  Is Debian just a hobby for a small 
population with unusual interests?

Regards,                          ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

[toc] | [prev] | [next] | [standalone]

#243610

On Thu 30 Dec 2021 at 19:48:05 (-0800), peter@easthope.ca wrote:
> 
> Debian 11 is easily arranged so that "startx" or "weston" can be 
> issued at the console command line.  That allows simple qualitative 
> comparisons.
> 
> In weston, keyboard response can be hyper-typematic.  The briefest 
> keypress can give at least two instances of the key action; sometimes a 
> half dozen.  That includes backspace.  Consequently keyboard input is 
> impossible. This happens not in every instance of weston but often 
> enough to be a nuisance. Has anyone else observed this?

Presumably Weston or your DE has some configuration option that allows
the typematic rate to be overridden. I only know the ones for VCs
(kbdrate) and X (xset r). The kbdrate can be set at @reboot in root's
crontab to make it possible to login at a text VC more easily, if
it's messing up your typing passwords.

There used to be constraints on what values would be accepted.
No idea whether that's still true.

On Sat 01 Jan 2022 at 11:21:09 (-0800), peter@easthope.ca wrote:
> 
> The two problems I described and the following are serious impairments 
> of the system.  A convincing explanation can help to solve a problem 
> but I have yet to find an explanation in these cases.  
> 
> Spontaneously, windows in the display vanish.  =8~(  If a toolbar is 
> present at the bottom of the display, it remains.  A mouse click on 
> the toolbar restores the vanished windows.  =8~)  Appears that mouse 
> activity triggers vanishing.  Happens once per hour or two.  
> Infrequently enough to tolerate but definitely a nuisance.  When 
> OpenBox is used without a toolbar, the only way I have to restore the 
> display is close OpenBox and open anew.  =8~(

As Stefan Monnier said, I'd be filing bug reports, but I think they'd
have to be described more clearly than the anecdotes above.

>     From: Johann Klammer <klammerj@a1.net>
>     Date: Fri, 31 Dec 2021 19:15:53 +0100
> > Haven't you noticed the x.org people f***ing stuff up since Xfree 
> > became x.org?
> > Why do you expect this to chsange?
> 
> I don't particularly expect progress but without progress Debian will 
> become an obsolete curiosity.  As have Atari ST and Amiga. 
> https://en.wikipedia.org/wiki/Atari_ST
> https://en.wikipedia.org/wiki/Amiga
> A few dedicated hobbyists use them.  They are not general purpose 
> workstations.
> 
> Incidentally, with a little dedication and skill Atari and Amiga 
> handle email.  That's textual email.  A MUA doesn't have to be a video 
> player.

Not for you and me, perhaps, but many people want it to look and
behave more like a browser. And I think that's also true of most
businesses.

> A boot loader doesn't have to be an operating system.

I'm not sure who you're criticising here. Are you expecting Debian
not to support either Grub or UEFI? Or did I fail to notice that
Debian had developed a Boot Loader?

> For progress to occur, maintainers need to acknowledge problems 
> honestly and address honestly.  "Try testing." and "Does the problem 
> remain in the new stable release?" might help; they aren't solutions.

Well, they might be if the upstream developer has fixed the problem
and Debian has included that fixed version in the stable release.

> Too much icing on top of a cake will make it fall over.  =8~(  Better 
> to remove some icing and focus on the lower layers of cake.  =8~)
> https://en.wikipedia.org/wiki/Wedding_cake

Eh?

> Johann, the tone of your question suggests (to me at least) that you 
> don't expect a Debian system to be a general purpose workstation.

I don't understand the connection that seems to be being made between
X.org and Weston. I thought the intention of the latter was to
supercede the former.¹ Or have I misunderstood? Are these screwups
occurring in X (startx) as well?

> Is the Linux workstation obsolete?  Is Debian just a hobby for a small 
> population with unusual interests?

¹ besides being a reference implementation of a Wayland compositor.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#243619

On Mon, 3 Jan 2022 at 14:05, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Thu 30 Dec 2021 at 19:48:05 (-0800), peter@easthope.ca wrote:

> > In weston, keyboard response can be hyper-typematic.

> The kbdrate can be set at @reboot in root's
> crontab to make it possible to login at a text VC more
> easily, if it's messing up your typing passwords.

Re early setting of typematic ...

These days all my root filesystems are in LUKS containers.

And one of my laptops was so hyper-typematic that there
was about a 50% chance of getting the 'cryptsetup open'
password accepted when prompted by the initrd.

While this was great for security ($ADVERSARY has
difficulty to boot the machine even if they stole the
password!), it was a bit inconvenient. And also not
great for security (gives $THEM multiple opportunities
to surveil your password as you type it over and over again) ;p

So I now run 'kbdrate' inside the initrd. This seems to have
solved the problem there and in all subsequent layers.

[toc] | [prev] | [next] | [standalone]

#243641

On Mon 03 Jan 2022 at 16:25:47 (+1100), David wrote:
> On Mon, 3 Jan 2022 at 14:05, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Thu 30 Dec 2021 at 19:48:05 (-0800), peter@easthope.ca wrote:
> 
> > > In weston, keyboard response can be hyper-typematic.
> 
> > The kbdrate can be set at @reboot in root's
> > crontab to make it possible to login at a text VC more
> > easily, if it's messing up your typing passwords.
> 
> Re early setting of typematic ...
> 
> These days all my root filesystems are in LUKS containers.
> 
> And one of my laptops was so hyper-typematic that there
> was about a 50% chance of getting the 'cryptsetup open'
> password accepted when prompted by the initrd.
> 
> While this was great for security ($ADVERSARY has
> difficulty to boot the machine even if they stole the
> password!), it was a bit inconvenient. And also not
> great for security (gives $THEM multiple opportunities
> to surveil your password as you type it over and over again) ;p
> 
> So I now run 'kbdrate' inside the initrd. This seems to have
> solved the problem there and in all subsequent layers.

I presume you do this by placing something like
  /sbin/kbdrate -r 8 -d 500 -s
± a shebang, into a file like
  /etc/initramfs-tools/scripts/<something>/kbdrate.sh
Which <something> is appropriate?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#243671

On Tue, 4 Jan 2022 at 08:42, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Mon 03 Jan 2022 at 16:25:47 (+1100), David wrote:

> > So I now run 'kbdrate' inside the initrd. This seems to have
> > solved the problem there and in all subsequent layers.

> I presume you do this by placing something like
>   /sbin/kbdrate -r 8 -d 500 -s
> ± a shebang, into a file like
>   /etc/initramfs-tools/scripts/<something>/kbdrate.sh
> Which <something> is appropriate?

Hi David,

Well, you are on the right track, but it did take quite a bit more
thinking than that for me, because I had to ensure that it ran ahead
of the interactive cryptsetup password prompt script in the initrd,
which was the tricky aspect.

But it all came together quite easily. And that particular issue
might be irrelevant for you, but I will explain it anyway to demystify
some details in the scripts that I share below. And it answers your question.

Anyway, I'm glad you responded to my hint and I encourage you to try it.

See 'man initramfs-tools' for the details.

Aside: everywhere I'm using '/usr/sbin/kbdrate' your system may or may
not require that string to be changed to '/sbin/kbdrate' in any or all
places I give below. You can use a boot parameter 'break=top' to
examine the initrd environment. If I do that, '/sbin' and '/usr/sbin'
contents look the same and
  # echo $PATH
  /sbin:/usr/sbin:/bin/:/usr/bin
so I don't think it matters much. I think maybe I did just specify
'/usr/sbin' in anticipation of the future. The only detail that I have
forgotten is if there is some reason why I have used '/sbin/kbdrate'
in script #2 below. I can't remember.

Anyway, let's talk about the two main steps taken from 'man
initramfs-tools':
Step #1: make '/usr/sbin/kbdrate' available in the initrd filesystem.
Step #2: a script to run '/usr/sbin/kbdrate' at the right time, with
the desired arguments.

Step #1:

is done with what the manpage calls a "configuration hook script".

These contain some boilerplate that I figured out by looking at other
similar scripts in /usr/share/initramfs-tools/hooks, and I came up
with this:

#-------------------------------------------------------
$ sudo cat /etc/initramfs-tools/hooks/my_kbdrate
#!/bin/sh
set -e
PREREQ=""
prereqs()
{
    echo "$PREREQ"
}
case "$1" in
    prereqs)
        prereqs
        exit 0
        ;;
esac
. /usr/share/initramfs-tools/hook-functions
# Hooks for loading kbdrate software into the initramfs
copy_exec /sbin/kbdrate
exit 0
$
#-------------------------------------------------------

The only line of real interest in that script is the 'copy_exec'
statement. And 'copy_exec' is in the 'hook-functions' file sourced in
the statement before. The rest is boilerplate that does nothing
in this case.

Once this is in place, I can use a boot parameter 'break=top'
to confirm that '/usr/sbin/kbrate' is installed in the initrd.

Step #2:

is done with what the manpage calls a "boot script" and this is what I
came up with:
#-------------------------------------------------------
$ sudo cat /usr/share/initramfs-tools/scripts/local-top/my_kbdrate
#!/bin/sh
PREREQ=""
prereqs()
{
    echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
    prereqs
    exit 0
    ;;
esac
f="/usr/sbin/kbdrate"
if [ -x "${f}" ]; then
    "${f}" -d 700 -r 20 >/dev/null
fi
$
#-------------------------------------------------------

There are a couple of unexpected aspects to script #2, which I will
explain ...

a) Script sequencing

or "Why has he put it under /usr ?"

All the PREREQ= and prereqs stuff is a mechanism to control the
sequencing of scripts in each subdirectory under
'*/initramfs-toos/scripts/'.

How to use that mechanism will depend on how the other scripts present
are already using it. Above I left it unused because I had to use a
different approach, so PREREQ was irrelevant and I never assigned it
any values. This seems common in other scripts too, when order does
not matter.

For my situation it was essential to ensure that Step #2 ran before
the interactive cryptsetup password prompt script in the initrd.

So I had to take note of where that occurs in the whole sequence of
different subdirectories, and ensure that my script ran before.

And a complicating factor is that 'man initramfs-tools' says:

  Please notice that PREREQ is only honored inside a single directory.
  So first the scripts in /usr/share/initramfs-tools are ordered
  according to their PREREQ values and executed. Then all scripts in
  /etc/initramfs-tools are ordered according to their PREREQ values and
  executed. This mean that currently there is no possibility to have a
  local script (/etc/initramfs-tools) get executed before one from the
  package (/usr/share/initramfs-tools).

Note the last sentence. Even though I suspect it ambiguously
overstates the problem, that explains why my script *must* be placed
in '/usr/..../local-top' subdirectory and not under /etc as would be
more desirable. I could not see any way to have it under /etc and
be sure that it would run early enough. I tried that, and it worked.

b) '/usr/sbin/kbdrate' options

Even though 'man kbdrate' says that '-s' does "No messages are
printed", this turns out to be untrue. So I used >/dev/null
instead.

And, after all that, it works \o/

ps: Happy New Year to all list readers :)

[toc] | [prev] | [next] | [standalone]

#243672

On Tue, 4 Jan 2022 at 14:40, David <bouncingcats@gmail.com> wrote:

> There are a couple of unexpected aspects to script #2, which I will
> explain ...
>
> a) Script sequencing
>
> or "Why has he put it under /usr ?"
>
> All the PREREQ= and prereqs stuff is a mechanism to control the
> sequencing of scripts in each subdirectory under
> '*/initramfs-toos/scripts/'.
>
> How to use that mechanism will depend on how the other scripts present
> are already using it. Above I left it unused because I had to use a
> different approach, so PREREQ was irrelevant and I never assigned it
> any values. This seems common in other scripts too, when order does
> not matter.
>
> For my situation it was essential to ensure that Step #2 ran before
> the interactive cryptsetup password prompt script in the initrd.
>
> So I had to take note of where that occurs in the whole sequence of
> different subdirectories, and ensure that my script ran before.
>
> And a complicating factor is that 'man initramfs-tools' says:
>
>   Please notice that PREREQ is only honored inside a single directory.
>   So first the scripts in /usr/share/initramfs-tools are ordered
>   according to their PREREQ values and executed. Then all scripts in
>   /etc/initramfs-tools are ordered according to their PREREQ values and
>   executed. This mean that currently there is no possibility to have a
>   local script (/etc/initramfs-tools) get executed before one from the
>   package (/usr/share/initramfs-tools).
>
> Note the last sentence. Even though I suspect it ambiguously
> overstates the problem, that explains why my script *must* be placed
> in '/usr/..../local-top' subdirectory and not under /etc as would be
> more desirable. I could not see any way to have it under /etc and
> be sure that it would run early enough. I tried that, and it worked.

Realised that I forgot to articulate something important
in that explanation ...

The other "boot script"
  /usr/share/initramfs-tools/scripts/local-top/cryptroot
is what provides the interactive cryptsetup password prompt.
And it contains prereqs() logic to ensure that it runs
*last* of all scripts in that '/usr/.../local-top' directory.

That is why my my_kdbrate script:
- must be in that directory /usr...local-top, so it runs before;
- cannot be placed under /etc, which would run after;
- does not need to specify any PREREQ, already managed.

[toc] | [prev] | [next] | [standalone]

#244162

    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Sun, 2 Jan 2022 21:05:00 -0600
> Presumably Weston or your DE has some configuration option that allows
> the typematic rate to be overridden. 

The behaviour is sporadic.  More likely a software "feature" rather 
than inappropriate configuration. 

> I'm not sure who you're criticising here.

Just unnecessary general grumbling.  =8~|

> Are these screwups occurring in X (startx) as well?

Strictly in weston.  On the old desktop machine, X works as well as 
ever. 

Thx,                                     ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web