https://bugs.winehq.org/show_bug.cgi?id=43125
--- Comment #12 from Kai Krakow kai@kaishome.de --- (In reply to Konrad Rzepecki from comment #10)
You have right I didn't see whole picture, but I think this is not needed as this code itself forbids some situations.
Les't assume that is something waiting for events in irp_queue.
- We enter critical section
- Set last_report_read FALSE
- A irp_queue is not empty enter while
- In while mark last_report_read to TRUE
- Exit while
- Exit critical section.
So if is something in irp_queue report is ALWAYS, at the end, marked as read. If in meantime, other calls appear to process_hid_report they didn't see FALSE in last_report_read because wait in beginning of critical section.
Only situation that last_report_read is FALSE outside critical section is when no one waits for events in irp_queue and while is not entered. But if no one wants the report, why spamming about it is not read?
Despite all of this I think this message should be rid off. It does nothing, report is overwritten despite of it. But this message itself broke console applications messing horribly its output. I my case i almost didn't see what applications writes to console but mostly this "0051:err:hid_report:process_hid_report Device reports coming in too fast, last report not read yet!" thing.
I'd like to fix this in two steps:
1. Make the message less spammy: Only display the message once as long as there are no readers in irp_queue.
2. Degrade the message to debug log level: As far as I understand the code and the logic behind the delivery design, having no readers for incoming reports is not an error condition. It's a warning at most, and a pretty uninteresting even unless you're debugging things.
What do you think?