You are not logged in.
Pages: 1
What I’m saying is it’s common for me to want to copy an arbitrary amount of text, so with the trackpoint, I move the cursor to the correct place, press and hold the left mouse button, and move the trackpoint to select my text. And when in X, on the touchpad, I’ll tap and drag to select an arbitrary amount of text. But on the console, I’ll attempt to tap and drag, but all that happens is a left click that does nothing because I’m probably just in the shell, followed by mouse motion.
Oh, I’m sorry, I said it wrong. This is such muscle memory for me that I fail to notice what I’m doing in order to describe it properly.
Yes, tapping is working for clicks.
Really what I don’t have is when you tap and then drag your finger in order to select an arbitrary amount of text, like what I get from holding the left mouse button and moving the mouse. That’s consistently what I want to do on console, and selecting words and lines is less common for me.
Right, the basic functionality of mouse motion works on the console, but the more advanced functions that I mentioned and linked to in my initial post, such as tapping, I haven’t managed to get working, and that was what I wanted to find out about.
Not that it’s terribly important, but I’m accustomed to tapping when in X, so on the console I reflexively tap first, see that nothing happened, and then use the physical button.
I have the feeling that you’re talking purely about configuring the touchpad under X11 and not about gpm and the console at all, but I’m not quite certain.
To be clear, you have taken some settings shown by synclient and put them in a gpm configuration file such as /etc/gpm-syn.conf, and, as a result, on the console, the touchpad now does more than simply move the mouse around?
Sure, I just didn’t want to engage in a time-consuming post if the answer was that it hasn’t worked in 15 years, which seemed quite likely with the state of GPM. This is daedalus on a thinkpad x201.
Linux semil 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux
[ 3.416876] psmouse serio1: synaptics: queried max coordinates: x [..5888], y [..4810]
[ 3.496504] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.4, id: 0x1e0b1, caps: 0xd047b1/0xb40000/0xa0000/0x0, board id: 0, fw id: 615624
[ 3.496650] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[ 3.546599] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input2
Did you have to do any GPM configuration to get the Synaptics features, or did it Just Work?
In https://raw.githubusercontent.com/telmi … .synaptics , there are tapping, scrolling, and so forth.
Does anyone have this working?
On the other hand, there was yet another set of xorg security updates that we don’t get because it's forked.
openssh-client finally showed up. I wonder why this security update took four days to make its way through Devuan.
That shows just xorg-server-source, but the runtime pieces have names like xserver-xorg-*. And the xserver-xorg-core in Daedalus is 2:21.1.7-3+deb12u2devuan1.
xorg-server had vulnerabilities fixed in Debian about six days ago. I know Devuan’s is forked because of the libseat situation.
In such a case, is “TODO: merge xorg-server security fixes” added to some list of items somewhere, or…?
About a day and a half ago, Debian announced “For the stable distribution (bookworm), these problems have been fixed in version 1:9.2p1-2+deb12u2.”
I haven’t seen the update, and pkginfo.devuan.org search for openssh* shows 1:9.2p1-2+deb12u1 for daedalus and no mention of daedalus-security.
Is something wrong?
There's a more recent fix in the X server that could be relevant: https://bugs.devuan.org/cgi/bugreport.cgi?bug=799. And, if nowhere else, I suppose you could get the old debs out of installation media.
Thanks!
I as well don’t want whatever else happens to be in daedalus-proposed-updates. How would I set my pinning properly?
I looked around and found apt_preferences(5), and I think I have an idea of what to do for Package and Pin-Priority, but it is not obvious what would be correct for Pin: release a= or n= to correspond to daedalus-proposed-updates.
I don’t want to get it wrong and make a mess and need more help to undo it all.
Another possibility is probably within the infinitude of git.devuan.org. Maybe something will happen on some branch in https://git.devuan.org/devuan/xorg-server/branches as an indication of code getting into Daedalus. Or maybe not. That might be not the right region of git at all.
One possibility might be to look at
https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=xorg
https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=*seat*
each day. I would have to recognize when version numbers had changed.
Given that I won’t be using that Daedalus system regularly until this has been fixed, what is the most efficient way to check periodically from somewhere else whether the fix has happened yet?
I'm not sure there is a bug report, but that particular issue of having multiple Xorg (in different VT) with seatd, is currently being worked on, and I believe an update is coming fairly soon.
I’m glad to know that!
I don’t see a bug report, but I’m not experienced with the bug tracker.
Would it be more appropriate to have this topic moved to a lower-level subforum where more of the right people might see it, since, strictly speaking, this subforum suggests being about things running on X and not about getting X to run.
If this forum is even capable of moving topics, that is.
I have always been using a plain startx in each, but using startx -- :1 for the second one fails in the same way.
I startx on one vt (pretty minimal, starts up a window manager).
I try to startx again on another vt — same user or different user — and it fails. seatd says "Could not add client: seat is VT-bound and has an active client".
Since I don’t know whether being VT-bound is good or bad, I found SEATD_VTBOUND=0 and tried that on the seatd invocation. But seatd is still unhappy because it still sees an active client regardless.
I presume switching away from a vt is supposed to make an X session become *not* active somehow.
It looks like FEATURE_C12 may be orphan_file. I'd heard that new mkfs.ext4 was going to use that feature by default, and that older versions of e2fsck weren't going to understand it
Pages: 1