[Intel-gfx] Mouse cursor disappearing with SNA rendering

[Daniel J Blueman]

On 22 June 2016 at 23:20, Daniel J Blueman <daniel at quora.org> wrote:
> On 17 Jun 2016 6:23 p.m., "Chris Wilson" <chris at chris-wilson.co.uk> wrote:
>>
>> On Fri, Jun 17, 2016 at 06:12:16PM +0800, Daniel J Blueman wrote:
>> > On 17 June 2016 at 17:18, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> > > On Fri, Jun 17, 2016 at 05:08:55PM +0800, Daniel J Blueman wrote:
>> > >> Hi all!
>> > >>
>> > >> When unlocking from lightdm, the mouse cursor isn't visible until
>> > >> switching VTs. This doesn't occur when using UXA rendering mode
>> > >> though, and affects a *lot* of people [1]. It occurs with a range of
>> > >> kernels including 4.6.2.
>> > >>
>> > >> I'm using xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1
>> > >> (current in Ubuntu 16.04 LTS).
>> > >>
>> > >> How can I approach debugging it?
>> > >
>> > > Start with a kernel from about 3.19. The trigger was introduced by
>> > > xorg-server-1.18.3 which double applied a SETCURSOR ioctl. That should
>> > > have been a noop...
>> >
>> > Thanks for replying Chris!
>> >
>> > I find the issue occurs in kernels 4.6.2, 4.4.13 and 4.3.6, but does
>> > not in 4.2.8 or 4.1.26, however I also see that locking the screen
>> > doesn't blank it, so there is behavioural difference also.
>> >
>> > This may result in a kernel bisect tripping on a large merge; I can
>> > take a look if you think the odds are ok?
>>
>> I would look at -nightly first and hope that is has been fixed (and that
>> the fix is trivial).
>
> No cigar with -nightly, so I'll follow up in a few days after I get through
> the 4.2-4.3 kernel bisection.

Needed an old toolchain to successfully boot these kernels; no issues
on 3.16, but the cursor disappears after screen locking and unlocking
on 3.17 and later kernels.

Due to some bisect skipping due to DPMS-on failure, it alas bisects to
some large merges as expected:

7707e6535f43328e05e4729ac96eee864b90e8a4
ca5a1b9ba0fb5291b555a23b76dbe5f6c30bfd7a
c51f71679042a5f388d9580ffbede14c897f1e86

Thanks,
  Daniel
-- 
Daniel J Blueman