Bug #7672

No mouse cursor in GNOME

Added by intrigeri 2014-07-27 23:29:25 . Updated 2014-10-02 14:11:27 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Target version:
Start date:
2014-10-02
Due date:
% Done:

100%

Feature Branch:
feature/jessie
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

In an ISO built from current feature/jessie, running in libvirt/qemu on a sid host, I see no mouse cursor in the Greeter.


Subtasks

Feature #7994: Wait for gnome-session 3.14 and friends to reach Jessie Rejected intrigeri

0


Related issues

Blocked by Tails - Feature #7311: Investigate using GNOME Shell for Jessie Resolved 2014-06-11

History

#1 Updated by intrigeri 2014-07-28 10:56:53

  • Status changed from New to Confirmed

#2 Updated by alant 2014-08-12 11:43:20

This issue appeared when GDM 3.12 landed in jessie. I suspect that the WM is now mutter and that without the shell rather than metacity we miss a component that displays the cursor. To be investigated further.

#3 Updated by BitingBird 2014-08-29 16:52:21

removing message that concerns 1.1

#4 Updated by anonym 2014-09-08 11:44:11

intrigeri wrote:
> In an ISO built from current feature/jessie, running in libvirt/qemu on a sid host, I see no mouse cursor in the Greeter.

There’s no mouse cursor in the GNOME session after Tails Greeter either. Also, the same problem occurs when reconfiguring gdm to log in directly to GNOME flashback.

This is in VirtualBox, btw, so I think the problem is universal.

#5 Updated by intrigeri 2014-09-08 19:45:49

> There’s no mouse cursor in the GNOME session after Tails Greeter either.

Confirmed in libvirt/qemu (built from 19d26980).

#6 Updated by alant 2014-09-12 15:00:29

  • Subject changed from No mouse cursor in the Jessie Greeter to No mouse cursor in GNOME
  • Category deleted (165)

#7 Updated by alant 2014-09-14 05:53:46

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 20
  • Starter changed from No to Yes

gsettings set org.gnome.settings-daemon.plugins.cursor active false solves the issue. It should be added to defaut dconf settings.

#8 Updated by alant 2014-09-14 07:29:43

  • % Done changed from 20 to 30
  • Feature Branch set to feature/jessie

Should be fixed in feature/jessie

#9 Updated by alant 2014-09-14 08:39:00

For some reason, the patch is not applied entierly.

#10 Updated by alant 2014-09-14 09:08:17

  • Status changed from In Progress to Resolved
  • % Done changed from 30 to 100

Now fixed.

#11 Updated by intrigeri 2014-09-14 21:48:20

  • Status changed from Resolved to In Progress
  • % Done changed from 100 to 50

alant wrote:
> Now fixed.

I’m happy that you found a workaround, and I’m sure it’ll help us work on the Jessie port more easily, but I disagree that we can call it “fixed”:

  • disabling a g-s-d plugin smells like a hackish workaround to me: I suspect we’re simply missing another package that would make that plugin work properly; disabling it entirely might have unwanted side-effects. I’m thinking e.g. of accessibility here: can we still configure the cursor via GNOME tools to make it more visible?
  • if we really need/want to patch greeter.dconf-defaults, then the patch should be renamed: it is still called gdm-tails-greeter.patch, while it’s scope is now broader.

#12 Updated by alant 2014-09-15 14:07:53

> disabling a g-s-d plugin smells like a hackish workaround to me:

I agree

> I suspect we’re simply missing another package that would make that plugin work properly;

It’s the only solution I found while searching for this problem on the web. Doesn’t look that easy.

> disabling it entirely might have unwanted side-effects. I’m thinking e.g. of accessibility here: can we still configure the cursor via GNOME tools to make it more visible?

Secondary click on long press works. I didn’t find the option to make the cursor more visible in accessibility preferences.

> if we really need/want to patch greeter.dconf-defaults, then the patch should be renamed: it is still called gdm-tails-greeter.patch, while it’s scope is now broader.

Why? This patch is only for the greeter (there is another change for the session).

#13 Updated by intrigeri 2014-09-19 22:34:00

> It’s the only solution I found while searching for this problem on the web. Doesn’t look that easy.

gnome-flashback 3.10.0-1 entered NEW, and it’s changelog reads:

       * Initial upload (closes: #758721).
       * This application solves some problems of the GNOME Flashback session:
         - It draws the background (which will fix #729846).
         - It manages user activity so that gnome-settings-daemon can
           show the mouse cursor.
         - It provides End Session dialogs (which will fix #755140).

So, if that’s a flashback mode -specific bug, then it’ll be solved as soon as we switch to some flavour of GNOME Shell. I expect more similar issues until then.

> Why? This patch is only for the greeter (there is another change for the session).

Ah, OK, sorry.

#14 Updated by intrigeri 2014-09-19 22:35:18

  • blocked by Feature #7311: Investigate using GNOME Shell for Jessie added

#15 Updated by intrigeri 2014-10-02 02:29:03

intrigeri wrote:
> gnome-flashback 3.10.0-1 entered NEW, and it’s changelog reads:

It has now reached testing. Time to try installing it, and reverting our hack.

#16 Updated by intrigeri 2014-10-02 06:31:37

  • Assignee changed from alant to intrigeri

I’m giving it a try.

#17 Updated by intrigeri 2014-10-02 09:08:37

In my branch that uses GNOME Classic for the regular session, and runs gnome-flashback in the Greeter’s one, I could successfully revert the disabling of the cursor g-s-d plugin, and I see the cursor both in the Greeter’s session and in the regular one (in virt-manager, host running current sid). So, I’ll close this ticket as resolved once it’s confirmed that we can indeed use GNOME Shell.

#18 Updated by intrigeri 2014-10-02 14:11:27

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • Type of work changed from Research to Code
  • Starter changed from Yes to No

intrigeri wrote:
> So, I’ll close this ticket as resolved once it’s confirmed that we can indeed use GNOME Shell.

That’s now the case.