As in a lot of other bug reports, tap-to-click is not enabled by default any more in various system components. This one is about GDM, which has no GUI configuration mechanism for changing this (or any other) setting. Tap-to-click has been enabled everywhere in MGA since forever. If some upstream genius has suddenly taken a dislike to it, I think we should enable it by default everywhere and see what arguments, if any, anyone can advance for reverting the change. Reproducible: Steps to Reproduce:
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=16941, https://bugs.mageia.org/show_bug.cgi?id=16575
Ping ?
Assigning to all packagers collectively, since there is no maintainer for this package. @ Frank Is this bug still valid?
Keywords: (none) => NEEDINFOCC: (none) => marja11Assignee: bugsquad => pkg-bugs
I don't know, as I haven't used GDM since I entered this. I imagine it is, because tap-to-click is turned off by default in GNOME.
(In reply to Frank Griffin from comment #3) > I don't know, as I haven't used GDM since I entered this. I imagine it is, > because tap-to-click is turned off by default in GNOME. @ Olav It would be nice to read your comment. See the Description of this report, too: (comment #0): <snip> > > Tap-to-click has been enabled everywhere in MGA since forever. If some > upstream genius has suddenly taken a dislike to it, I think we should enable > it by default everywhere and see what arguments, if any, anyone can advance > for reverting the change.
Keywords: NEEDINFO => (none)CC: (none) => olav
I don't want to spend time to figure out why this has changed (and no clue where to look). It's probably because it caused some complications. If some effort is put into figuring it out why default was changed then seems we're in good state to decide if Mageia should deviate and/or maybe fix upstream.
Olav, you're the maintainer. Nobody else is going to have the expertise to figure out why this was done, or whether it was even intentional. The bottom line is that every touchpad user in the world expects tap-to-click to work. If you dump something into cauldron that breaks that, it's up to you to justify it if you can. Don't feel singled out - Plasma5 does this as well, and I've opened a bug for that as well.
Well as you mentioned Olav is the maintainer, which means that he packages what upstream develops, and when really necessary, may try to come up with some patches (but ideally those should come from upstream too). It might be sensible for Mageia to deviate from upstream's recommendation, but before this is decided, it should be discussed upstream. If, after discussion, we consider that upstream's choice is bad for our distro, then we can patch it and maintain our patch for as long as we'll disagree with upstream.
In reply to Olav Vitters from comment #5) > (and no clue where to look). In reply to Frank Griffin from comment #6) > Olav, you're the maintainer. Oh well. I actually did investigate. It is not done within GDM. There's various other bits, gnome-settings-daemon, gsettings-desktop-schemas. They all never had this enabled (going back to 2009 at least). Already said no clue where to look. Bit I maintain weren't changed, so closing the bug.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME
BTW: This is a WORKSFORME for GDM. If the behaviour should be changed, bug should be filed against the correct component. And still no clue where.
$ mgarepo maintdb get gdm nobody
1) Isn't GDM part of GNOME ? 2) Since tap-to-click isn't enabled for GNOME or the install either, isn't the logical suspect GTK3 ? 3) I'm reopening this because WORKSFORME makes no sense. The statement of the bug is that tap-to-click is not enabled by default, so at the moment that works for nobody. If the component is in error, I could change that to GTK3, but that would come back to you anyway, no ?
Status: RESOLVED => REOPENEDResolution: WORKSFORME => (none)
(In reply to Frank Griffin from comment #11) > 1) Isn't GDM part of GNOME ? Yes. What has that to do with anything? > 2) Since tap-to-click isn't enabled for GNOME or the install either, isn't > the logical suspect GTK3 ? I investigated, and the defaults I found weren't changed since 2009. If you want to investigate, feel free. I've already stated that, hey, no clue what changed or where. I could phrase it differently, but honestly, no idea. Could even be udev not setting some right parameter for all I know. > 3) I'm reopening this because WORKSFORME makes no sense. The statement of > the bug is that tap-to-click is not enabled by default, so at the moment > that works for nobody. If the component is in error, I could change that to > GTK3, but that would come back to you anyway, no ? $ mgarepo maintdb get gtk+3.0 nobody I've said enough times that it is NOT my responsibility to figure out what changed. Figure out the component, file a bug against the correct component. Just because you see it in GDM makes it a problem for the GDM maintainer (if we'd have one). Just because you guess GTK+3.x doesn't make it ok to just reassign it. As said various times: there will be NO progress on this from my side. It's pretty damn rude to continue saying other people should do the investigation for you, while I made abundantly clear that hey, it is NOT in GDM, not various other components. I am NOT the "GNOME" maintainer. Mageia has maintainers per package, I usually set the maintainer to nobody to make it abundantly clear that I contribute while _NOT_ being to The usual triaging rules are pretty damn easy: You filed a bug against GDM, saying the default changes. I checked, it didn't. WORKSFORME is the right resolution for GDM. Changing it randomly to other components without checking anything is NOT the right process for a bugreport. Anyway, as WORKSFORME was not ok, I'll choose a random other resolution, starting top down.
Keywords: (none) => NEEDINFOStatus: REOPENED => RESOLVEDResolution: (none) => FIXEDSource RPM: gdm => (none)
Reopening because there does seem to be a problem to investigate, although we don't know where to. It's assigned to packagers collectively now, not to you Olav, and chosing a random resolution is not something we as bug triage team can accept. Or, Frank you could open a different bug report so that we start anew without all the angry commentaries, that would be probably clearer.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
OK, I had opened 4 bugs for tap-to-click being disabled by default, one for GDM, one for SDDM (https://bugs.mageia.org/show_bug.cgi?id=16941 ), one for Plasma ( https://bugs.mageia.org/show_bug.cgi?id=16685 ), and one for the Installer ( https://bugs.mageia.org/show_bug.cgi?id=16575 ), so I'll close this one and open another for GDM. I didn't bother opening one for GNOME as I knew the reception that would get.
Status: REOPENED => RESOLVEDResolution: (none) => MOVED
Moved to https://bugs.mageia.org/show_bug.cgi?id=18936 .
(In reply to Frank Griffin from comment #14) > OK, I had opened 4 bugs for tap-to-click being disabled by default, one for > GDM, one for SDDM (https://bugs.mageia.org/show_bug.cgi?id=16941 ), one for > Plasma ( https://bugs.mageia.org/show_bug.cgi?id=16685 ), and one for the > Installer ( https://bugs.mageia.org/show_bug.cgi?id=16575 ), so I'll close > this one and open another for GDM. I didn't bother opening one for GNOME as > I knew the reception that would get. Couldn't all those bug reports you opened have the same root cause and be regrouped into one single bug report?
Yes, they could, and I assumed they did, but the maintainer for the primary suspect in the case (GTK+) swears it isn't responsible, and I don't know what else these use cases have in common.
(In reply to Frank Griffin from comment #17) > Yes, they could, and I assumed they did, but the maintainer for the primary > suspect in the case (GTK+) swears it isn't responsible, and I don't know > what else these use cases have in common. Obviously not GTK+ since Plasma is affected and uses Qt5...
(In reply to Rémi Verschelde from comment #18) > (In reply to Frank Griffin from comment #17) > > Yes, they could, and I assumed they did, but the maintainer for the primary > > suspect in the case (GTK+) swears it isn't responsible, and I don't know > > what else these use cases have in common. > > Obviously not GTK+ since Plasma is affected and uses Qt5... And there's no registered maintainer for GTK+, different people happen to maintain it as they can.
CC: olav => (none)