Does this group have any real Linux users or is everyone just
a bunch of distro-freeloading and useless kibitzers?

Help with this -- if you fucking can.

I desire a relatively slow pointing device (i.e. mouse) motion,
but with the now mandatory (i.e. no choice) libinput driver
under X Window I have a hard time understanding how to configure
the motion.

Using "xinput list" I discover that my pointing device is
device id=8.

Thus:

xinput list-props 8

....
....
Device 'PixArt Microsoft USB Optical Mouse':
Device Enabled (155): 1
Coordinate Transformation Matrix (157): 0.400000, 0.000000, 0.000000, 0.000000, 0.400000, 0.000000, 0.000000, 0.000000, 1.000000
....
....

The motion is apparently controlled by this "transformation
matrix," which seems to be 3x3 in size.

As seen above, I have what I assume to be the x and y motion
set to 0.4.

This does indeed slow the motion down.

But what do the rest of the values accomplish?

I can find no documentation on this issue. If someone can
provide links or a description then do it.

But I suspect there will only be more useless kibitzing.

On 7/2/2024 3:21 PM, Farley Flud wrote:
> Does this group have any real Linux users or is everyone just
> a bunch of distro-freeloading and useless kibitzers?
>
> Help with this -- if you fucking can.
>
> I desire a relatively slow pointing device (i.e. mouse) motion,
> but with the now mandatory (i.e. no choice) libinput driver
> under X Window I have a hard time understanding how to configure
> the motion.
>
> Using "xinput list" I discover that my pointing device is
> device id=8.
>
> Thus:
>
> xinput list-props 8
>
> ...
> ...
> Device 'PixArt Microsoft USB Optical Mouse':
> Device Enabled (155): 1
> Coordinate Transformation Matrix (157): 0.400000, 0.000000, 0.000000, 0.000000, 0.400000, 0.000000, 0.000000, 0.000000, 1.000000
> ...
> ...
>
> The motion is apparently controlled by this "transformation
> matrix," which seems to be 3x3 in size.
>
> As seen above, I have what I assume to be the x and y motion
> set to 0.4.
>
> This does indeed slow the motion down.
>
> But what do the rest of the values accomplish?
>
> I can find no documentation on this issue. If someone can
> provide links or a description then do it.
>
> But I suspect there will only be more useless kibitzing.

That's a 'normalized matrix' with coordinates between 0 and 1.

https://github.com/kreijack/xlibinput_calibrator/blob/master/src/calibrator.cc#L144
line 216

and

https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/src/evdev.c
line 2554

On Tue, 2 Jul 2024 16:21:10 -0400, DFS <nospam@dfs.com> wrote in
<66846135$0$970$882e4bbb@reader.netnews.com>:

> On 7/2/2024 3:21 PM, Farley Flud wrote:
>> Does this group have any real Linux users or is everyone just a bunch
>> of distro-freeloading and useless kibitzers?
>>
>> Help with this -- if you fucking can.
>>
>> I desire a relatively slow pointing device (i.e. mouse) motion, but
>> with the now mandatory (i.e. no choice) libinput driver under X Window
>> I have a hard time understanding how to configure the motion.
>>
>> Using "xinput list" I discover that my pointing device is device id=8.
>>
>> Thus:
>>
>> xinput list-props 8
>>
>> ...
>> ...
>> Device 'PixArt Microsoft USB Optical Mouse':
>> Device Enabled (155): 1 Coordinate Transformation Matrix
>> (157): 0.400000, 0.000000, 0.000000, 0.000000, 0.400000,
>> 0.000000, 0.000000, 0.000000, 1.000000
>> ...
>> ...
>>
>> The motion is apparently controlled by this "transformation matrix,"
>> which seems to be 3x3 in size.
>>
>> As seen above, I have what I assume to be the x and y motion set to
>> 0.4.
>>
>> This does indeed slow the motion down.
>>
>> But what do the rest of the values accomplish?
>>
>> I can find no documentation on this issue. If someone can provide
>> links or a description then do it.
>>
>> But I suspect there will only be more useless kibitzing.
>
>
> That's a 'normalized matrix' with coordinates between 0 and 1.
>
> https://github.com/kreijack/xlibinput_calibrator/blob/master/src/
calibrator.cc#L144
> line 216
>
> and
>
> https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/src/evdev.c
> line 2554

2557:

/* The transformation matrix is in the form:
* [ a b c ]
* [ d e f ]
* [ 0 0 1 ]
* Where a, e are the scale components, a, b, d, e are the rotation
* component (combined with scale) and c and f are the translation
* component. The translation component in the input matrix must be
* normalized to multiples of the device width and height,
* respectively. e.g. c == 1 shifts one device-width to the right.
*
* We pre-calculate a single matrix to apply to event coordinates:
* M = Un-Normalize * Calibration * Normalize
*
* Normalize: scales the device coordinates to [0,1]
* Calibration: user-supplied matrix
* Un-Normalize: scales back up to device coordinates
* Matrix maths requires the normalize/un-normalize in reverse
* order.
*/

"Use the Source, Luke!"

--
-v ASUS TUF Dash F15 x86_64 NVIDIA RTX 3060 Mobile
OS: Linux 5.15.0-113-lowlatency Release: Mint 21.3 Mem: 15.9G

Le 02-07-2024, Farley Flud <ff@linux.rocks> a écrit :
> Does this group have any real Linux users

Some, but you are not one of them.

> or is everyone just
> a bunch of distro-freeloading and useless kibitzers?

That's where you belong. You can manage to fool yourself but you can't
fool anyone else.

> Help with this

Why?

> -- if you fucking can.

s/can/want/

> I desire

Who cares about what you desire? Not me.

> a relatively slow pointing device (i.e. mouse) motion,

Now, I understand why you despise the mouse when unable to get rid of
it. It's as slow as you when you dream to be fast.

> I have a hard time understanding

Yes, of course, it's obvious.

> how to configure the motion.

Use the keyboard: it's what you keep saying.

> Device 'PixArt Microsoft USB Optical Mouse':

Now, you are a Microsoft lackey, too. Good to know.

> But I suspect there will only be more useless kibitzing.

You get what you deserve.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Farley Flud <ff@linux.rocks> wrote:
> Does this group have any real Linux users or is everyone just
> a bunch of distro-freeloading and useless kibitzers?
>
> Help with this -- if you fucking can.
>
> I desire a relatively slow pointing device (i.e. mouse) motion,
> but with the now mandatory (i.e. no choice) libinput driver
> under X Window I have a hard time understanding how to configure
> the motion.
>
> Using "xinput list" I discover that my pointing device is
> device id=8.
>
> Thus:
>
> xinput list-props 8
>
> ...
> ...
> Device 'PixArt Microsoft USB Optical Mouse':
> Device Enabled (155): 1
> Coordinate Transformation Matrix (157): 0.400000, 0.000000, 0.000000, 0.000000, 0.400000, 0.000000, 0.000000, 0.000000, 1.000000
> ...
> ...
>
> The motion is apparently controlled by this "transformation
> matrix," which seems to be 3x3 in size.
>
> As seen above, I have what I assume to be the x and y motion
> set to 0.4.
>
> This does indeed slow the motion down.
>
> But what do the rest of the values accomplish?

The rest of the values turn it into a mathematical structure
called a "matrix", so that all the coordinates can be represented
as matrices and transformations can be applied by multiplying
matrices together. The technique comes from the game industry,
where it allows graphical transforms to be done quickly.

Matrices can be used to directly represent all sorts of
graphical transformations. For example, this matrix, when
multiplied by a matrix representing a 3D coordinate,
rotates the coordinate around the origin:

[ cos(angle) sin(angle) 0.0
-sin(angle) cos(angle) 0.0
0.0 0.0 1.0 ]

There's also a matrix to scale a vector, which is likely
what the matrix in your configuration is doing. If you
multiply a translation matrix representing how far the
mouse has moved by a scaling matrix, you get a new translation
matrix that represents a smaller movement.

You can multiply an arbitrary number of transformation matrices
together and get a single matrix that will apply all the
transformations in the order you multiplied them (matrix
multiplication is not commutative, unlike ordinary
multiplication), when you multiply a set of coordinates by that
matrix.

You could do this independently of X11, and plug in a transformation
matrix that causes your mouse to behave as if you were holding it
sideways or upside down.

> I can find no documentation on this issue. If someone can
> provide links or a description then do it.

The documentation is in some math book somewhere, but I learned
about matrices on the Internet. It was many years ago, so I
don't have a link handy. This would be a good topic to run
by an LLM, while they're still allowed to talk about math.

There was once a description of a naive (and therefore easy
to understand) algorithm for multiplying matrices on Wikipedia.
It might still exist.

On Thu, 29 Aug 2024 05:27:49 -0000 (UTC), Sebastian wrote:

>
> The rest of the values turn it into a mathematical structure
> called a "matrix", so that all the coordinates can be represented
> as matrices and transformations can be applied by multiplying
> matrices together.
>

Close but no cigar.

You failed to explain why a 3x3 matrix is used to effect 2D
transformations which would only require a 2x2 matrix.

The reason is the use of HOMOGENEOUS COORDINATES (HC).

Using HC we can lump both translations, rotations, and shear
into a single matrix.

But regardless, a matrix transformation only effects changes
in spatial coordinates. I am referring to MOTION or VELOCITY.
How do the matrix components affect velocity and acceleration?
Does the matrix define a unit translation that is repeated
after a time interval?

--
Systemd: solving all the problems that you never knew you had.

On 8/29/2024 1:27 AM, Sebastian wrote:
> Farley Flud <ff@linux.rocks> wrote:
>> Does this group have any real Linux users or is everyone just
>> a bunch of distro-freeloading and useless kibitzers?
>>
>> Help with this -- if you fucking can.
>>
>> I desire a relatively slow pointing device (i.e. mouse) motion,
>> but with the now mandatory (i.e. no choice) libinput driver
>> under X Window I have a hard time understanding how to configure
>> the motion.
>>
>> Using "xinput list" I discover that my pointing device is
>> device id=8.
>>
>> Thus:
>>
>> xinput list-props 8
>>
>> ...
>> ...
>> Device 'PixArt Microsoft USB Optical Mouse':
>> Device Enabled (155): 1
>> Coordinate Transformation Matrix (157): 0.400000, 0.000000, 0.000000, 0.000000, 0.400000, 0.000000, 0.000000, 0.000000, 1.000000
>> ...
>> ...
>>
>> The motion is apparently controlled by this "transformation
>> matrix," which seems to be 3x3 in size.
>>
>> As seen above, I have what I assume to be the x and y motion
>> set to 0.4.
>>
>> This does indeed slow the motion down.
>>
>> But what do the rest of the values accomplish?
>
> The rest of the values turn it into a mathematical structure
> called a "matrix", so that all the coordinates can be represented
> as matrices and transformations can be applied by multiplying
> matrices together. The technique comes from the game industry,
> where it allows graphical transforms to be done quickly.
>
> Matrices can be used to directly represent all sorts of
> graphical transformations. For example, this matrix, when
> multiplied by a matrix representing a 3D coordinate,
> rotates the coordinate around the origin:
>
> [ cos(angle) sin(angle) 0.0
> -sin(angle) cos(angle) 0.0
> 0.0 0.0 1.0 ]
>
> There's also a matrix to scale a vector, which is likely
> what the matrix in your configuration is doing. If you
> multiply a translation matrix representing how far the
> mouse has moved by a scaling matrix, you get a new translation
> matrix that represents a smaller movement.
>
> You can multiply an arbitrary number of transformation matrices
> together and get a single matrix that will apply all the
> transformations in the order you multiplied them (matrix
> multiplication is not commutative, unlike ordinary
> multiplication), when you multiply a set of coordinates by that
> matrix.
>
> You could do this independently of X11, and plug in a transformation
> matrix that causes your mouse to behave as if you were holding it
> sideways or upside down.

Hey Slimer (the 'fags, niggers and jeets' and Jew-hatred in your other
'Sebastian' posts gave you away),

Nice answer above. Where did you learn so much about matrix math?

And I see you're running tin:

User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-18-amd64
(x86_64))

So which distro are you subjecting yourself to at the moment?

Aside: have you been keeping up with the successes Robby Starbuck - and
boycotts - has had in smacking down DEI and wokeness in large American
corporations? Tractor Supply, John Deere, Harley-Davidson, and Lowes
[so far] have made statements rescinding much of their previous
commitment to DEI and LGBTQ sickness, which doesn't belong in business
anyway.

On Thu, 29 Aug 2024 05:27:49 -0000 (UTC), Sebastian wrote:

> There was once a description of a naive (and therefore easy to
> understand) algorithm for multiplying matrices on Wikipedia.
> It might still exist.

Check out Khan Academy. He goes beyond rote manipulations to proofs.

Farley Flud <ff@linux.rocks> wrote:
> On Thu, 29 Aug 2024 05:27:49 -0000 (UTC), Sebastian wrote:
>
>>
>> The rest of the values turn it into a mathematical structure
>> called a "matrix", so that all the coordinates can be represented
>> as matrices and transformations can be applied by multiplying
>> matrices together.
>>
>
> Close but no cigar.
>
> You failed to explain why a 3x3 matrix is used to effect 2D
> transformations which would only require a 2x2 matrix.
>
> The reason is the use of HOMOGENEOUS COORDINATES (HC).
>
> Using HC we can lump both translations, rotations, and shear
> into a single matrix.
>
> But regardless, a matrix transformation only effects changes
> in spatial coordinates. I am referring to MOTION or VELOCITY.
> How do the matrix components affect velocity and acceleration?
> Does the matrix define a unit translation that is repeated
> after a time interval?

My guess is that the transformation matrix doesn't represent
motion or velocity, but is applied in a stepwise manner every
time the position of the cursor is updated (likely after polling
the mouse driver), presumably by applying a translation matrix to
its previous position. The 0.4s in your matrix would make the
translations smaller, which results in slower cursor movement. I
doubt acceleration is being calculated.

On Mon, 16 Sep 2024 08:28:32 -0000 (UTC), Sebastian wrote:

>
> My guess is that the transformation matrix doesn't represent
> motion or velocity, but is applied in a stepwise manner every
> time the position of the cursor is updated (likely after polling
> the mouse driver), presumably by applying a translation matrix to
> its previous position. The 0.4s in your matrix would make the
> translations smaller, which results in slower cursor movement. I
> doubt acceleration is being calculated.
>

A transformation matrix cannot represent velocity but only
translation, rotation, and shear.

Likely, as I mentioned, the "velocity" is effected by applying
the matrix at step intervals, but there is no documentation of
which I am aware that describes this.

But acceleration seems to be addressed. Here is the libinput
dump of the optical mouse (device = 8):

xinput -list-props 8

Device 'PixArt USB Optical Mouse':
Device Enabled (155): 1
Coordinate Transformation Matrix (157): 0.400000, 0.000000, 0.000000, 0.000000, 0.400000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Natural Scrolling Enabled (283): 0
libinput Natural Scrolling Enabled Default (284): 0
libinput Scroll Methods Available (285): 0, 0, 1
libinput Scroll Method Enabled (286): 0, 0, 0
libinput Scroll Method Enabled Default (287): 0, 0, 0
libinput Button Scrolling Button (288): 2
libinput Button Scrolling Button Default (289): 2
libinput Button Scrolling Button Lock Enabled (290): 0
libinput Button Scrolling Button Lock Enabled Default (291): 0
libinput Middle Emulation Enabled (292): 0
libinput Middle Emulation Enabled Default (293): 0
libinput Rotation Angle (266): 0.000000
libinput Rotation Angle Default (267): 0.000000
libinput Accel Speed (294): 0.000000
libinput Accel Speed Default (295): 0.000000
libinput Accel Profiles Available (296): 1, 1, 1
libinput Accel Profile Enabled (297): 1, 0, 0
libinput Accel Profile Enabled Default (298): 1, 0, 0
libinput Accel Custom Fallback Points (299): <no items>
libinput Accel Custom Fallback Step (300): 0.000000
libinput Accel Custom Motion Points (301): <no items>
libinput Accel Custom Motion Step (302): 0.000000
libinput Accel Custom Scroll Points (303): <no items>
libinput Accel Custom Scroll Step (304): 0.000000
libinput Left Handed Enabled (305): 0
libinput Left Handed Enabled Default (306): 0
libinput Send Events Modes Available (268): 1, 0
libinput Send Events Mode Enabled (269): 1, 0
libinput Send Events Mode Enabled Default (270): 0, 0
Device Node (271): "/dev/input/event0"
Device Product ID (272): 1118, 203
libinput Drag Lock Buttons (307): <no items>
libinput Horizontal Scroll Enabled (308): 1
libinput Scrolling Pixel Distance (309): 15
libinput Scrolling Pixel Distance Default (310): 15
libinput High Resolution Wheel Scroll Enabled (311): 1

Note the numerous options for "Accel" which apparently control various
aspects of the pointer acceleration.

Again, I am not not aware of any documentation, other than the probably
intractable source code, that describes these options.

But since things work to my satisfaction I feel no need to research
this any further.

--
Systemd: solving all the problems that you never knew you had.