Version: (using KDE 4.2.3) OS: Linux Installed from: Debian testing/unstable Packages Using tuxonice 3.0.1 on Linux kernel 2.6.29.3 (but also saw this for previous versions of the Linux Kernel & Tuxonice): Suspend to & Resume from disk works fine, but after resume the KDE Write Daemon floods the screen with messages (approximately 40-50) from the suspend and the resume processes, most of which are empty or single-line (containing host name). Proposed fix: Ignore suspend & resume for KDE Write Daemon messages unless it failed, as the user will likely have noticed that the machine turned off/on again.
There are some cases where this behavior appears and it's not only on suspend/resume. The problem is that the kernel notifies all terminals about this and sends one line at a time. kwrited on the client side generates a notification for each message it receives, which produces all those single-line notifications. I will try to figure something out to group messages in one notification.
Do you think it might make sense to have the notification daemon configurable via a filter that allows to determine what the user wants to see - and what the user would prefer to have suppressed?
Ping? What is the status of this problem? I am wondering because thie report has remained silent for quite a long time.
The status is the same, nothing has really changed. To be honest, I consider this a really minor problem, as normally the user should see no notifications from kwrited. If the kernel spams you with millions of error messages when you do something specific, then there is obviously something wrong with the kernel, not with kwrited. I agree though that kwrited should group all those messages in one notification, not spawn thousands of them. However, even in this case the notification won't be very pleasant to see (it will probably fill the whole screen). Plus, there is only one way to do this and it's a bit hacky: there needs to be a timer to wait for a while for new messages, collect all of them in a buffer and show them together. This is a bad approach, but I don't think there is any alternative. If anybody wants to try that, feel free.