Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1184453 - mouse cursor is invisible for 1 minute after log in, g-s-d seems to be stuck waiting for cups
Summary: mouse cursor is invisible for 1 minute after log in, g-s-d seems to be stuck ...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F22BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2015-01-21 12:49 UTC by Kamil Páral
Modified: 2015-01-27 22:38 UTC (History)
16 users (show)

Fixed In Version: cups-2.0.1-2.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-27 13:05:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
system journal after the 1 minute timeout has passed (159.33 KB, text/plain)
2015-01-21 12:50 UTC, Kamil Páral
no flags Details
rpm -qa output (44.82 KB, text/plain)
2015-01-21 12:50 UTC, Kamil Páral
no flags Details
gnome terminal before timeout - graphical glitch (258.69 KB, image/png)
2015-01-21 12:51 UTC, Kamil Páral
no flags Details
gnome-terminal after timeout - no glitch (258.74 KB, image/png)
2015-01-21 12:51 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2015-01-21 12:49:48 UTC
Description of problem:
When I log in to Rawhide, I don't see my mouse cursor (I see it in gdm, but it disappears after logging in). The cursor works, it's just invisible. After exactly 1 minute, it appears (you need to move it in order to make it appear).

This is the backtrace of gnome-setting-daemon during the 1 minute timeout:
#0  0x00007f76dcf3814d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f76b1a64167 in poll (__timeout=60000, __nfds=1,
    __fds=0x7fff11509a50) at /usr/include/bits/poll2.h:46
#2  _httpWait (http=<optimized out>, msec=60000, usessl=<optimized out>)
    at http.c:3188
#3  0x00007f76b1a64494 in httpGets (line=line@entry=0x7fff11509af0 "",
    length=length@entry=32768, http=http@entry=0x26551c0) at http.c:1205
#4  0x00007f76b1a64a4b in _httpUpdate (http=http@entry=0x26551c0,
    status=status@entry=0x7fff11511b34) at http.c:2923
#5  0x00007f76b1a64d6b in httpUpdate (http=http@entry=0x26551c0) at http.c:3112
#6  0x00007f76b1a85ae8 in cupsGetResponse (http=http@entry=0x26551c0,
    resource=resource@entry=0x7f76b1a939b7 "/") at request.c:388
#7  0x00007f76b1a869b9 in cupsDoIORequest (http=0x26551c0, http@entry=0x0,
    request=request@entry=0x263c9c0,
    resource=resource@entry=0x7f76b1a939b7 "/", infile=infile@entry=-1,
    outfile=outfile@entry=-1) at request.c:250
#8  0x00007f76b1a86c56 in cupsDoRequest (http=http@entry=0x0,
    request=request@entry=0x263c9c0,
    resource=resource@entry=0x7f76b1a939b7 "/") at request.c:312
#9  0x00007f76b1a5591a in _cupsGetDests (http=http@entry=0x0,
    op=op@entry=IPP_OP_CUPS_GET_PRINTERS, name=name@entry=0x0,
    dests=dests@entry=0x2550a20, type=type@entry=0, mask=mask@entry=0)
    at dest.c:1523
#10 0x00007f76b1a56b6c in cupsGetDests2 (http=http@entry=0x0,
    dests=dests@entry=0x2550a20) at dest.c:1745
#11 0x00007f76b1a56e02 in cupsGetDests (dests=dests@entry=0x2550a20)
    at dest.c:1692
#12 0x00007f76b1cb75cd in gsd_print_notifications_manager_start_idle (
    data=0x2550a70) at gsd-print-notifications-manager.c:1308
#13 0x00007f76dd46ce1b in g_main_dispatch (context=0x2468730) at gmain.c:3122
#14 g_main_context_dispatch (context=context@entry=0x2468730) at gmain.c:3737
#15 0x00007f76dd46d1b0 in g_main_context_iterate (context=0x2468730,
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at gmain.c:3808
#16 0x00007f76dd46d4d2 in g_main_loop_run (loop=0x24a7c90) at gmain.c:4002
#17 0x00007f76df0074b5 in gtk_main () at gtkmain.c:1208
#18 0x00000000004037d3 in main (argc=1, argv=0x7fff1151b818) at main.c:427

This is the backtrace after 1 minute timeout:
#0  0x00007f76dcf3814d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f76dd46d14c in g_main_context_poll (priority=2147483647, n_fds=9, fds=0x2635560, timeout=53980,
    context=0x2468730) at gmain.c:4103
#2  g_main_context_iterate (context=0x2468730, block=block@entry=1, dispatch=dispatch@entry=1,
    self=<optimized out>) at gmain.c:3803
#3  0x00007f76dd46d4d2 in g_main_loop_run (loop=0x24a7c90) at gmain.c:4002
#4  0x00007f76df0074b5 in gtk_main () at gtkmain.c:1208
#5  0x00000000004037d3 in main (argc=1, argv=0x7fff1151b818) at main.c:427

It seems something is wrong with cups and g-s-d printer plugin. At least that's what Bastien Nocera thinks:

<hadess> kparal, file a bug against gnome-settings-daemon and its printers plugin
<hadess> and talk to mkasik, because cups

There's also one more indicator that something is wrong. During the 1 minute timeout, gnome-terminal has a black rectangle in the top left corner. Once the minute passes, the rectangle disappears and the mouse cursor appears, at the same time.

Version-Release number of selected component (if applicable):
gnome-settings-daemon-3.15.1-1.fc22.x86_64
cups-2.0.1-1.fc22.x86_64
cups-client-2.0.1-1.fc22.x86_64
cups-filesystem-2.0.1-1.fc22.noarch
cups-filters-1.0.61-2.fc22.x86_64
cups-filters-libs-1.0.61-2.fc22.x86_64
cups-libs-2.0.1-1.fc22.x86_64
cups-pk-helper-0.2.5-5.fc22.x86_64

How reproducible:
100% on both VM and bare metal

Steps to Reproduce:
1. boot the computer
2. see the cursor in gdm
3. log in
4. don't see the cursor
5. wait a minute, move the mouse
6. see the cursor again

Additional info:
The Rawhide has been installed using F21 netinst installer, just using Rawhide yum repo.

Comment 1 Kamil Páral 2015-01-21 12:50:17 UTC
Created attachment 982304 [details]
system journal after the 1 minute timeout has passed

Comment 2 Kamil Páral 2015-01-21 12:50:37 UTC
Created attachment 982305 [details]
rpm -qa output

Comment 3 Kamil Páral 2015-01-21 12:51:02 UTC
Created attachment 982307 [details]
gnome terminal before timeout - graphical glitch

Comment 4 Kamil Páral 2015-01-21 12:51:23 UTC
Created attachment 982308 [details]
gnome-terminal after timeout - no glitch

Comment 5 Kamil Páral 2015-01-21 12:55:56 UTC
I'm proposing this as an F22 Alpha Blocker, because it violates all our desktop-related criteria - you can hardly operate e.g. a web browser or the very gnome-shell interface without a cursor.

I'd appreciate more testing from other people without a different environment, maybe this can be caused by some local network printers or something.

Comment 6 Mathieu Bridon 2015-01-21 17:11:12 UTC
I'm seeing the same bug on my Rawhide laptop.

I have no printers here, neither local nor on the network.

Comment 7 Adam Williamson 2015-01-21 17:34:00 UTC
Oh, someone finally tracked this down? Good. I see it in a clean VM, but not on my daily-use desktop (which does have a printer).

I'm not totally sure I'd agree it's an Alpha blocker as the cursor *does* appear after a fairly short delay, but it'd certainly be good to have it fixed, and I'd definitely be +1 Final and possibly Beta.

Comment 8 Russel Winder 2015-01-25 18:14:57 UTC
Just to chip in a few observations in the hope it helps someone solve the problem:

I see the problem on my laptops (Lenovo T500 and Lenovo X201), but not on my workstation (Dell Precision T5400, GeForce 610 graphics card). All have my two printers defined. The workstation has to run kernel 3.18 because the NVIDIA driver will not install in 3.19-rcX, the laptops are running 3.19-rc5. I haven't tried with 3.18 on the laptops.

Brightness control does not work during the "no cursor" period. As soon as the cursor appears, brightness control works fine. 

Whilst early adopters can cope with a short period of missing cursor, I feel this should be treated as an immediate blocker as it is really infuriating even to early adopters.

Comment 9 Chris Murphy 2015-01-26 08:12:03 UTC
I see it on a Dell XPS 9333 laptop, it's a problem so I'm +1 as alpha blocker.

Comment 10 Marek Kašík 2015-01-26 16:44:54 UTC
This is a bug in cups. I can reproduce the problem using "lpstat -s" from console. It is probably a problem in activating of cups via socket. Second run of "lpstat -s" is not delayed even when run during run of the first one.
It worked with cups-1.7.5-7.

I'm reassigning this bug to cups.

Comment 11 Dan Mossor [danofsatx] 2015-01-26 17:28:00 UTC
Discussed a Fedora Blocker Review Meeting 2015-01-26

http://meetbot.fedoraproject.org/fedora-blocker-review/2015-01-26/f22-blocker-review.2015-01-26-17.00.log.txt

AcceptedBlocker for Beta - This bug conditionally violates the Alpha criterion ""It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." by making it difficult/impossible to do anything within the GUI, the violation is considered serious enough to block Beta but not Alpha

Comment 12 Tim Waugh 2015-01-27 12:39:47 UTC
The systemd notify support had broken in the port to 2.0.0.

Comment 13 Kamil Páral 2015-01-27 13:31:34 UTC
Great, this new build fixes the problem for me! Can somebody else confirm?

Comment 14 Adam Williamson 2015-01-27 22:38:37 UTC
Yup, confirmed here also. (I think it also fixed https://bugzilla.gnome.org/show_bug.cgi?id=741683 , for me...)


Note You need to log in before you can comment on or make changes to this bug.