Adam Jackson <a...@nwnk.net> writes: > Exposing edge/level in ospoll_add is a bit funky, you're silently > degrading edge to level if the OS backend can't do edge. kqueue could do > it if the code were written, and I suspect win32's WaitForMultipleObjects > could be made to do it if we got really wild, but Solaris doesn't have an > edge-triggered API for this at all (does have port_create which is > basically level-triggered epoll, but).
Good comment here. poll(2) doesn't have edge-triggered options either, so the ospoll code emulates that by remembering the previous value and not reporting when it hasn't changed. This requires a call to ospoll_reset_events in io.c to clear the previous value when input runs dry. > If the intent is that asking for edge is an indication that the caller > _can_ use edge-triggers but will work with either then I guess that's > fine. A comment to that effect would be good. Could do it this way as well, and would eliminate the ospoll_reset_events interface. The only cost would be extra calls to the callback for clients which have input and are not getting serviced, which is not a big deal as that doesn't actually happen all that often in normal X usage. dix handles this just fine; checking to see if the client is on the ready list before inserting it. Sounds like a good change to me as it will simplify the poll(2) interface. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
