(In reply to Alex Deucher from comment #73)
> (In reply to Benjamin from comment #72)
> > I'm having the same issue, but it seems to be getting worse with =
newer
> > kernels. I was able to do the suspend/resume trick to get a worki=
ng screen,
> > but this seems to have stopped working with kernel 3.16 and 3.17.=
 No amount
> > of suspending/resuming seems to get the screen to appear now, so =
I've had to
> > stick with 3.15 for the time being. I'm on Arch, so packages are =
fairly
> > generic, but I can provide any information that would help.
>=20
> Can you bisect and see what commit made it worse?  That might help nar=
row
> down the problem.

Alex, I=E2=80=99ll soon have access to that device again. Unfortunately, do=
ing a bisect
for me does not work as there is no clear way to figure out if it worked or
not.

Isn=E2=80=99t there some software, testing =E2=80=9Call panel timings=E2=80=
=9D and the user can say,
which worked?

That Asus laptop is/was one of the few AMD laptops out there, so it=E2=80=
=99s sad that
GNU/Linux doesn=E2=80=99t run properly on it.