Home Forums Software Development Using setdisplayarea tool

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #4948
    Louis dAboville

    Hi there,

    I need to use an EyeX tracker in a non standard setup (large screen, therefore EyeX needs to be mounted close to user)

    If I use the display area calculator, and run setdisplayarea.exe will this only affect data I get from the Gaze SDK?

    Also, if I run setdiplayarea.exe and then run the included WpfCalibrationSample is the non standard screen setup taken into account?

    I am reasonably familiar with Unity and C#, and have made a few programs with the EyeX SDK but the C++ Gaze SDK looks pretty daunting and would like to avoid it if at all possible!

    Louis dAboville

    Can’t test this myself for a few days but need to plan best course of action for an upcoming project

    Grant [Tobii]

    Hi @leskos,

    This tool can be used to set and store a new display area in the eye tracker.

    It can be used with the Tobii Gaze SDK and its samples.

    Unfortunately it cannot be used without problems with EyeX Tracker, since the EyeX software will overwrite the display area whenever it evaluates changes on the system that can affect calibration, screen resolution and other eye tracking settings – for example when logging in, when reconnecting to the eye tracker, or when there is a “Display Settings Changed” event from Windows.

    Therefore we can only recommend using the setdisplayarea tool with the Tobii Gaze SDK, on systems where EyeX is not installed (or at least not running).

    Louis dAboville


    Thanks for clarifying that.

    In theory though, would it affect the gaze point given by the Unity SDK? (still can’t test until later this week)

    If so, are these all the cases in which EyeX engine would overwrite the display area? I am looking at using it in a setting where I would have exclusive control over the machine, and could automate the running of setdisplayarea when needed.

    Jenny [Tobii]

    Hi @leskos,

    Yes, it would affect the gaze point given by the Unity SDK. EyeX would overwrite both the display area and the calibration (these two always do together), and you would end up with the eye tracker using a configuration for a different physical setup than the one you have. Since the eye tracker has to be calibrated for each specific screen setup, this also means that you have to do a custom calibration from the Tobii Gaze SDK (there are samples of that in the SDK).

    The list of cases when the EyeX Engine would overwrite the display area (and calibration among other things) were just an example list. There is no fixed list of cases of when this happens and we cannot give such a list because it might change at any future release of the EyeX Engine. Internally we are using a call to Revalidate the eye tracking setup from different places in the code, it might be related to for example revalidating EyeX Settings or display settings because there might be a risk of inconsistency or because we know we need to update values due to system changes, or when the eye tracker is disconnected and reconnected, or when reloading the user profile. During revalidation all things are revalidated together to make sure the total configuration is consistent. This means that there are many different kinds of reasons for and chains of events resulting in revalidating the setup and there is no way of listing an exhaustive list including all corner cases of when this happens. It might be possible to work around if you have full control of the system – it might also not be possible to work around. I can’t say for sure. I would not know how to work around it myself, and I’m one of the developers who wrote the original revalidation routine in the EyeX Engine.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.