[Mesa-dev] Manipulate GALLIUM_HUD post-launch (interactively)

[Eero Tamminen]

Hi,

On 10/29/2015 12:27 PM, Martin Peres wrote:
> On 29/10/15 12:33, Eero Tamminen wrote:
>> On 10/28/2015 11:24 PM, Jimmy Berry wrote:
>>> I have found myself desiring the ability to manipulate the GALLIUM_HUD
>>> variable while an application is running. At the most basic simply
>>> being able to toggle the hud on and off would be great. Otherwise, one
>>> has to relaunch an application and get back to the same state which
>>> may not always be trivial.
>>>
>>> Obviously there are a lot of other possibilities for such a mechanism
>>> even manipulating other variables interactively.
>>>
>>> I discussed the idea with imirkin_ on #dri-devel who agreed that
>>> something like a socket interface would be a reasonable way to
>>> approach the problem, but suggested I toss out the idea on the mailing
>>> list to acquire more thoughts.
>>>
>>> I have extensive development experience, but none in the kernel nor
>>> mesa space. If desirable I would be interested in attempting to
>>> implement this idea.
>>
>> Some other possibilities than socket:
>>
>> * Using (non-blocking) fifo, so that it can be more easily controlled
>> from shell script than with socket
>>
>> * Using signal to toggle the HUD
>>
>> Signal handler should be set only when user requests it, e.g. with
>> environment variable (that way Mesa doesn't by itself steal signals
>> from applications).
>
> You cannot depend on signals in libraries. The application may have
> replaced the library's handler with its own.

I meant that the enabling environment variable would also specify what 
signal is used for toggling:
	MESA_TOGGLE_HUD_WITH_SIG=<signal>

User can check from /proc/PID/status file what signals are unused.


One more possibility is Mesa monitoring debug config file changes and 
re-reading the options after it notices that file has been updated.

As to when and how that monitoring is done, it's something that could 
also be enabled with environment variable (MESA_RUNTIME_CONFIG=yes). 
Implementation could use inotify in another thread, check file timestamp 
on every frame, or have (user-specified) signal for telling that file 
should be re-read.  That kind of mechanism could be used to control many 
other things at run-time too.


	- Eero