Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

From: Stefan Monnier 
Date: Sat, 01 Jan 2022 16:23:10 -0500
> I suggest you file a bug report.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004358

Regards, ... P.


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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

The References list was becoming too long.  I've truncated it.

From: Andrei POPESCU 
Date: Fri, 21 Jan 2022 10:15:56 +0100
> According to the manpage '--display' is an X11 option.
> 
> Could it be that it actually forces Firefox to run via XWayland or so?

Right oh.  I added this to .bashrc and tried on weston.

firew () { case "$#" in
  0) firefox-esr file:///home/peter/MY/Peter.html#Links & ;;
  1) firefox-esr "$1" & ;;
  *) echo "Too many arguments." ;; esac
  }

Unfortunately, no improvement apparent.

Thx,  ... P.


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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Tixy]

On Sun, 2022-01-23 at 15:25 -0800, pe...@easthope.ca wrote:
[...]
> Lines toward the end merit attention.
> 
> * Beginning at [14:32:22.019] ... Microsoft 3-Button Mouse with IntelliEye 
> ... events have been lost. 
> 
> * [14:32:28.210] ... Microsoft 3-Button Mouse ... rate limit exceeded (5 msgs 
> per 30s). ...
> 
> 5 msgs per 30s exceeds a rate limit in a computer?  Granted this is an 
> old machine but it's a computer not an abacus.

That limit is on the rate the kernel produces the messages, a lot of
warnings are programmed that way to avoid spamming your logs too much.

-- 
Tixy

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

From: Andrei POPESCU 
Date: Fri, 21 Jan 2022 10:15:56 +0100
> According to the manpage '--display' is an X11 option.
> 
> Could it be that it actually forces Firefox to run via XWayland or so?

I should find a way to know the variant of FF which is running.  
Xwayland or weston native.

Before pursuing that, I've put the stderr output from weston at 
http://easthope.ca/WestonStdErr . Plain ASCII text.  Firefox opens it.

Lines toward the end merit attention.

* Beginning at [14:32:22.019] ... Microsoft 3-Button Mouse with IntelliEye ... 
events have been lost. 

* [14:32:28.210] ... Microsoft 3-Button Mouse ... rate limit exceeded (5 msgs 
per 30s). ...

5 msgs per 30s exceeds a rate limit in a computer?  Granted this is an 
old machine but it's a computer not an abacus.

The observed hyper-typematic behaviour is related to lost mouse events?

A bug report is materializing but further ideas welcome.

Thx,   ... P.

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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Andrei POPESCU]

On Ma, 18 ian 22, 08:10:30, pe...@easthope.ca wrote:
> 
> Thanks.  Revised version.
> 
> fire () { case "$#" in
>   0) firefox-esr --display=:0 file:///home/peter/MY/Peter.html#Links & ;;
>   1) firefox-esr --display=:0 "$1" & ;;
>   *) echo "Too many arguments." ;; esac
> }

According to the manpage '--display' is an X11 option.

Could it be that it actually forces Firefox to run via XWayland or so?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

From: Greg Wooledge 
Date: Tue, 18 Jan 2022 07:22:53 -0500
> "$1" should be quoted there, and the } will need to be on a separate line,
> or else you'll need a semicolon between esac and }.
> 
> I'd also advise against hard-coding paths like /usr/bin/firefox-esr in
> your dot files.  Paths can change over time.  Just use firefox-esr.

> Also, you wouldn't want "exec" here -- running this alias would terminate the 
> shell.

Thanks.  Revised version.

fire () { case "$#" in
  0) firefox-esr --display=:0 file:///home/peter/MY/Peter.html#Links & ;;
  1) firefox-esr --display=:0 "$1" & ;;
  *) echo "Too many arguments." ;; esac
}

> For almost every purpose, aliases are superseded by shell functions.

Casting to C and compiling is also a nice exercise.  

Thanks,   ... P.







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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Greg Wooledge]

On Mon, Jan 17, 2022 at 08:13:58PM -0800, pe...@easthope.ca wrote:
> This shell function is defined in .bashrc and used to start firefox.
> 
> fire () { case $# in
>   0) /usr/bin/firefox-esr --display=:0 file:///home/peter/MY/Peter.html#Links 
> & ;;
>   1) /usr/bin/firefox-esr --display=:0 $1 & ;;
>   *) echo "Too many arguments." ;; esac }

"$1" should be quoted there, and the } will need to be on a separate line,
or else you'll need a semicolon between esac and }.

I'd also advise against hard-coding paths like /usr/bin/firefox-esr in
your dot files.  Paths can change over time.  Just use firefox-esr.

> This might be better.
> alias fire='exec /usr/bin/firefox-esr --display=:0 "$@"'

Bash aliases don't take positional parameters like that.  Also, you
wouldn't want "exec" here -- running this alias would terminate the shell.

Since bash aliases don't take positional parameters, there's really no
way to do the background thing with arguments using an alias.  So, stick
with the function here.  As the bash(1) manual says,

   There  is no mechanism for using arguments in the replacement text.  If
   arguments are needed, a shell function should be  used  (see  FUNCTIONS
   below).

And,

   For almost every purpose, aliases are superseded by shell functions.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

From: David Wright 
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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

From: Andrei POPESCU 
Date: Wed, 12 Jan 2022 19:29:33 +0100
> Works fine here, out of the box, on a pretty bare bones installation (no 
> X or Desktop Environment).

Yesterday evening, tried Weston briefly on a Vaio PCG-71312L.  No 
obvious problems.

 > Are you passing any special parameters to Firefox? 
 
This shell function is defined in .bashrc and used to start firefox.

fire () { case $# in
  0) /usr/bin/firefox-esr --display=:0 file:///home/peter/MY/Peter.html#Links & 
;;
  1) /usr/bin/firefox-esr --display=:0 $1 & ;;
  *) echo "Too many arguments." ;; esac }

This might be better.
alias fire='exec /usr/bin/firefox-esr --display=:0 "$@"'

> Currently I'm setting 'MOZ_ENABLE_WAYLAND=1', ...

In .bashrc here.
export MOZ_ENABLE_WAYLAND=1

When there's time, can make a bug report.

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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Andrei POPESCU]

Slightly late to the party ;)

On Jo, 30 dec 21, 19:48:05, pe...@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?

Works fine here, out of the box, on a pretty bare bones installation (no 
X or Desktop Environment).

> 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?

Are you passing any special parameters to Firefox? 

Currently I'm setting 'MOZ_ENABLE_WAYLAND=1', but don't remember if this 
was necessary to get Firefox to even start or I just wanted to make 
really sure Firefox is running natively on Wayland (i.e. without some X 
compatibility layer or something).

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David]

On Tue, 4 Jan 2022 at 14:40, David  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.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David]

On Tue, 4 Jan 2022 at 08:42, David Wright  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//kbdrate.sh
> Which  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 

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David Wright]

On Mon 03 Jan 2022 at 16:25:47 (+1100), David wrote:
> On Mon, 3 Jan 2022 at 14:05, David Wright  wrote:
> > On Thu 30 Dec 2021 at 19:48:05 (-0800), pe...@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//kbdrate.sh
Which  is appropriate?

Cheers,
David.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David]

On Mon, 3 Jan 2022 at 14:05, David Wright  wrote:
> On Thu 30 Dec 2021 at 19:48:05 (-0800), pe...@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.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David Wright]

On Thu 30 Dec 2021 at 19:48:05 (-0800), pe...@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), pe...@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 
> 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.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

Stefan & all,

From: Stefan Monnier 
Date: Sat, 01 Jan 2022 16:23:10 -0500
> I haven't and haven't heard of other people experiencing this until the
> above message.  

I'm still curious about adoption of Wayland/Weston by people reading 
here.  Does anyone use Weston routinely?  Start Weston, try one or a 
few applications briefly and return to X?

> I suggest you file a bug report.

Well yes.  Did my duty this week with a report against udev. Next week 
I might report the problem with X.  While Weston remains so slow, it 
will be a very low priority.

Incidentally, a little progress with X.  In my usage, X begins with 
multiple desktops.  Default behaviour here; I didn't choose it.  A 
spontaneous switch to an empty desktop leaves a display which is 
completely black for OpenBox; mostly black when a desktop environment 
is present.  In the desktop environment the toolbar has an icon 
allowing reversion to the working desktop.  Annoying but not critical.

In OpenBox the black screen was puzzling until I noticed that MM gives 
a desktop switch menu. Reverting to the working desktop is simple 
enough.  =8~)  (MM = middle mouse)

Multiple desktops is a cute embellishment  =8~|  but the installation 
default should be a single desktop.  Let the user add desktops 
according to taste.

Regards, ... P.




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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Curt]

On 2022-01-01, Stefan Monnier  wrote:
>> 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?
>
> I haven't and haven't heard of other people experiencing this until the
> above message.  I suggest you file a bug report.

I've never heard the expression "hyper-typematic" and neither has my
search engine, so even the neological description appears to confine to
the very narrowest of corner cases.



> Stefan
>
>

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

From: Johann Klammer 
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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Georgi Naplatanov]

On 1/1/22 19:14, pe...@easthope.ca wrote:
> Hello Georgi,
> 
> Thanks for the reply and greetings for the New Year.
> 
> From: Georgi Naplatanov 
> Date: Fri, 31 Dec 2021 22:41:43 +0200
> Message-id: <[] 10e5a66a-e9f9-1d1a-a67b-a283fb5c7...@oles.biz>
> In-reply-to: <[] E1n38th-rt-2j@joule>
> References: <[] E1n38th-rt-2j@joule>
> 
>> I just tested Firefox on KDE and Wayland (on Debian testing) and I
>> didn't notice any issue. 
> 
> Two possibilities.
> (1) Your machine architecture is generally more advanced than mine. 
> Latencies aren't noticeable.
> 
> (2) Your machine has one or more ASIC chips lacking here.  An ASIC 
> accelerating graphic processing might prevent latencies.
> 
>> I tried a few clips on youtube.com 
> 
> For youtube I use an Alcatel tablet.  
> 
>> ... and a few sites for open source software.
> 
> The desktop here is primarily for email and editing in Wikimedia 
> projects. Ie. shunting characters.  Even an old 486 machine can do 
> that. The difficulties are in the interface rather than in computing 
> power.
> 

I tried on VirtualBox and CPU is Intel(R) Core(TM) i7-8700 CPU @
3.20GHz, GPU is the embedded one in the CPU - Intel UHD Graphics 630

Happy new year!

Kind regards
Georgi

Re: Hyper-typematic and Firefox responsiveness in Weston.

[peter]

Hello Georgi,

Thanks for the reply and greetings for the New Year.

From: Georgi Naplatanov 
Date: Fri, 31 Dec 2021 22:41:43 +0200
Message-id: <[🔎] 10e5a66a-e9f9-1d1a-a67b-a283fb5c7...@oles.biz>
In-reply-to: <[🔎] E1n38th-rt-2j@joule>
References: <[🔎] E1n38th-rt-2j@joule>

> I just tested Firefox on KDE and Wayland (on Debian testing) and I
> didn't notice any issue. 

Two possibilities.
(1) Your machine architecture is generally more advanced than mine. 
Latencies aren't noticeable.

(2) Your machine has one or more ASIC chips lacking here.  An ASIC 
accelerating graphic processing might prevent latencies.

> I tried a few clips on youtube.com 

For youtube I use an Alcatel tablet.  

> ... and a few sites for open source software.

The desktop here is primarily for email and editing in Wikimedia 
projects. Ie. shunting characters.  Even an old 486 machine can do 
that. The difficulties are in the interface rather than in computing 
power.

Thanks,  ... P.

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

Re: Hyper-typematic and Firefox responsiveness in Weston.

[tomas]

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


signature.asc
Description: PGP signature

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Georgi Naplatanov]

On 12/31/21 05:48, pe...@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?
> 

Hi Peter,

I just tested Firefox on KDE and Wayland (on Debian testing) and I
didn't notice any issue. I tried a few clips on youtube.com and a few
sites for open source software.

Kind regards
Georgi

Re: Hyper-typematic and Firefox responsiveness in Weston.

[Johann Klammer]

On 12/31/2021 05:10 AM, pe...@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?

Hyper-typematic and Firefox responsiveness in Weston.

[peter]

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.




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