You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, if you wait a second or so (probably a few hundred milliseconds will do) the same call will succeed.
I suppose it makes sense, the kernel has to handle for example the replugging of an extension, but this behaviour isn't documented anywhere and even xwiishow.c doesn't seem to be affected by it (I'm guessing some ncurses calls there are slow enough to not have this issue?).
The text was updated successfully, but these errors were encountered:
There is devtype "pending" that supposed to signal device was just connected and you should initialize it on next WATCH event. However, for freshly connected devices devtype is "unknown" instead. As such, I currently retry every second until device type is not unknown, but having "pending" status work properly would be great.
This is trickier for extensions, since those don't have something like "pending" status even by design. This means that I have to delay processing of WATCH events by 500ms to avoid file not found/access denied errors.
but having "pending" status work properly would be great.
For a second I was wondering why this would be relevant, but now I understand. You're saying the lack of a "pending" status means we can not check if the device is ready to be checked for events again. However rather than a pending status for extensions, I rather have the watch event being send only after it's ready to listen for events again. I'm checking for new events in a loop every few milliseconds anyway, it can work just fine with no events till it's ready again.
However, if you wait a second or so (probably a few hundred milliseconds will do) the same call will succeed.
I suppose it makes sense, the kernel has to handle for example the replugging of an extension, but this behaviour isn't documented anywhere and even
xwiishow.c
doesn't seem to be affected by it (I'm guessing some ncurses calls there are slow enough to not have this issue?).The text was updated successfully, but these errors were encountered: