![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
call me, beep me, if you wanna reach me
Oct. 18th, 2007 02:29 pmMy girls have enjoyed Disney's Kim Possible, and the title is from the theme song. Much older than Disney's high school wanna-be spy girl is the X protocol. One of the elements in the X protocol is Bell (request code 104).
The X protocol allows for specification of the volume, pitch, and duration of the bell, but these are purely advisory. No hardware is required to support all the features, and there are no implementation guidelines in the X protocol. There are no guidelines about what to do if a series of Bell requests is received faster than the hardware is capable of implementing them. Should the Bell requests be queued, or should they be dropped?
Through the history of devices with X servers various vendors have placed various amounts of effort into handling the Bell request. The best vendors provided sufficient capability for their X servers to play music, but with any given server, on any given hardware, there are simply no guarantees.
The observatory recently had to implement a rather in-your-face feature to avoid a situation where an observer put a telescope at significant risk of damage. Part of this feature included an X11 GUI which used the Bell request. When it was tested on the mountain it worked just fine. When it was exercised remotely it caused the X server to become poorly responsive.
After a bunch of other folks tested and scratched their heads they came to me. (I'm the only one who has the X protocol reference manual on my shelf.) I explained the inconsistencies in X server implementation of Bell, but even with multiple test scripts they couldn't diagnose the issue. I came over and suggested a simple script which sent multiple Bell requests. Bingo, we saw the same behavior as in the GUI. The X server on the mountain apparently drops repeated Bell requests when a previous Bell request is in progress (I don't think it would play music well). The X server at the remote sites queues up repeated requests, and also becomes unresponsive while doing so.
Moral of the story: Just because you've tested your GUI on one X server, don't expect that it will behave the same on any other.
The X protocol allows for specification of the volume, pitch, and duration of the bell, but these are purely advisory. No hardware is required to support all the features, and there are no implementation guidelines in the X protocol. There are no guidelines about what to do if a series of Bell requests is received faster than the hardware is capable of implementing them. Should the Bell requests be queued, or should they be dropped?
Through the history of devices with X servers various vendors have placed various amounts of effort into handling the Bell request. The best vendors provided sufficient capability for their X servers to play music, but with any given server, on any given hardware, there are simply no guarantees.
The observatory recently had to implement a rather in-your-face feature to avoid a situation where an observer put a telescope at significant risk of damage. Part of this feature included an X11 GUI which used the Bell request. When it was tested on the mountain it worked just fine. When it was exercised remotely it caused the X server to become poorly responsive.
After a bunch of other folks tested and scratched their heads they came to me. (I'm the only one who has the X protocol reference manual on my shelf.) I explained the inconsistencies in X server implementation of Bell, but even with multiple test scripts they couldn't diagnose the issue. I came over and suggested a simple script which sent multiple Bell requests. Bingo, we saw the same behavior as in the GUI. The X server on the mountain apparently drops repeated Bell requests when a previous Bell request is in progress (I don't think it would play music well). The X server at the remote sites queues up repeated requests, and also becomes unresponsive while doing so.
Moral of the story: Just because you've tested your GUI on one X server, don't expect that it will behave the same on any other.
