https://bugzilla.kernel.org/show_bug.cgi?id=215880 --- Comment #53 from Paul Ausbeck (paula@xxxxxxxxxxxxxxxxxxx) --- I sense that we are in disagreement. In my way of thinking disagreement is overcome through logical argument. So here goes. I argue that you can't call a bug fixed if the fix introduces a serious, entirely separate, regression. I further argue that at resume the mouse pointer should be interactive at the same time that the display becomes active. I further argue that if the mouse pointer is not interactive at any time that the display is active, that is a serious UX bug. I further argue that before the recent kernel ATA changes this particular bug did not exist and therefore it is a regression. I further argue that though the regression is UX related it cannot be patched over outside of the kernel. I further argue that this regression likely affects any personal machine that contains a spinning disk and that this class of machines is substantial in size. I further argue that your reported deadlock between ata resume and scsi resume likely affects a far smaller class of machines. I further argue that though for a single machine deadlock is a more important problem than temporary lack of mouse pointer interactivity, for the kernel as a whole, problem importance is proportional to the multiplication of the individual seriousness and the size of the set of affected machines. I further argue that your assertion that the non-interactive mouse pointer is not related to the libata resume changes is incorrect. I further argue that the two dmesg fragments that I have posted to this thread explain the situation quite clearly. My argument contains 10 assertions. If you disagree with any of them, please give details. In particular I don't have a clear idea of the size of the set of machines that might experience the "fixed" ata/scsi resume deadlock. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
