# Deploy an Embedded Linux project > Deploy your project for Embedded Linux. On the Embedded Linux player, Unity uses SDL2 to handle keyboard, mouse, and controller input to interact with the Player window. Depending on the graphics API used, it requires SDL to dynamically load `libEGL` and `libGLESv2` for OpenGL ES, or `libvulkan` for Vulkan from the user space. ## Setup for [Wayland](https://wiki.archlinux.org/title/Wayland) Although this setup assumes that you're using [Weston](https://gitlab.freedesktop.org/wayland/weston) (the reference Wayland server), you can use the same setup with slight modifications for another compositor. ## Prerequisites This assumes that you have a Wayland compositor (Weston) running, which exports the Wayland socket in the directory that the environment variable `XDG_RUNTIME_DIR` is linked to. ### Setup on Desktop shell To deploy your project on desktop shell: 1. Verify that the environment variable `XDG_RUNTIME_DIR` is set to the correct directory. If not, then run `export XDG_RUNTIME_DIR=` with the correct directory (`/run/user/1000/ `is the default for a Weston installation). 2. Run Unity Player. ### Setup on IVI-shell extension You can deploy your project using IVI-shell extension, which is an alternative shell extension for Weston. 1. Set up IVI Surface IDs that the Unity Player needs using one of the following methods: * **Using C# code**: Set the `iviSurfaceID` property of the [EmbeddedLinuxGameWindowCreationSettings](/engine/6000.7/script-reference/unityengine/windowing/embeddedlinux/embeddedlinuxgamewindowcreationsettings.md) when creating a game window. * **Using the environment variable**: Set `UNITY_IVI_SURFACE_IDS` to a comma-separated list of IDs. For example, `export UNITY_IVI_SURFACE_IDS=100,200,300 uses ID` `100` to Display 1 and `200` to Display 2. If you're only using a single display output, a single ID is sufficient. For example, export `UNITY_IVI_SURFACE_IDS=100`. > **Note:** > > If you don't set the Surface ID using either of the methods, the Unity Player uses IDs starting from `4711` based on each camera's **Target Display** setting configured in the Unity Editor. For example, Display 1 uses `4711` and Display 2 uses `4712`. 2. Verify that the environment variable `XDG_RUNTIME_DIR`is set to the correct directory. If this isn't set, run `export XDG_RUNTIME_DIR=` with the correct directory (`/run/user/1000/` is the default for a Weston installation). 3. Run the Unity Player. 4. Use the following steps to set up an IVI surface for Unity (example, `weston` to `fullscreen map` surface). 1. Create IVI Layer. `LayerManagerControl create layer 0 ` 2. Add Layer on Screen. `LayerManagerControl set screen 0 render order 0` 3. Add Unity Player Surface on Layer. `LayerManagerControl set layer 0 render order ` 4. Add Surface Source Region. `LayerManagerControl set surface source region 0 0 ` 5. Add Surface Destination Region. `LayerManagerControl set surface destination region 0 0 ` 6. Add Layer Visibility. `LayerManagerControl set layer 0 visibility 1` 7. Add Surface Visibility. `LayerManagerControl set surface visibility 1` Unity Player appears on screen. ## Display configuration using environment variables When deploying your application on Embedded Linux, you can use the following environment variables to configure the display surface and input regions. ### Configure surface sizes with UNITY\_IVI\_EXPORT\_DISPLAYS By default, Unity creates surfaces of the same size as the physical displays. If you want to use surfaces other than physical displays, such as for rendering multiple surfaces to one screen, use the environment variable `UNITY_IVI_EXPORT_DISPLAYS`. For example, `export UNITY_IVI_EXPORT_DISPLAYS=1024x768@60,1920x1080@60`. This defines the following surface sizes for Unity displays: * Unity Display 1: `1024x768` * Unity Display 2: `1920x1080` Both displays will use a refresh rate of 60 Hz. > **Note:** > > You can omit `@60` and use `export UNITY_IVI_EXPORT_DISPLAYS=1024x768,1920x1080 `because the refresh rate of `60` is automatically assumed. ### Configure input regions with UNITY\_SURFACE\_INPUT\_REGIONS Use the `UNITY_SURFACE_INPUT_REGIONS` environment variable to define a rectangular input region relative to the Unity application Wayland surface, where (0,0) is the top-left corner of the surface. Only the area defined as the input region receives user inputs, such as touch or mouse clicks. Inputs outside the region pass through to any surface behind the Unity application. Enter the input for the environment variable in `xywh` format with no spaces. To define an input region, use the environment variable as follows: `export UNITY_SURFACE_INPUT_REGIONS=xywh` Consider the following behavior when defining the input region: * Negative input values (For example, `x-100`) are parsed without causing an error, but are treated as invalid. The input region isn't applied. * Inputs outside the visible surface region are applied, but a warning appears in the Unity Player log. * Input regions with zero area are applied, but a warning appears in the Unity Player log. #### Example `export UNITY_SURFACE_INPUT_REGIONS=x50y50w100h100` This defines an input region with: * Top-left corner at (50,50) relative to the Unity Wayland surface (0,0) * Width: 100 * Height: 100 If your Unity application runs on a `200x200` surface, using `UNITY_SURFACE_INPUT_REGIONS=x50y50w100h100` defines an input region as depicted in the following diagram: **Defining an input region with the environment variable:** ![](/api/media?file=/engine/6000.7/media/images/define-input-region.svg) For a Unity application running on multiple displays, define one input region per display by separating the arguments with commas, as follows: `export UNITY_SURFACE_INPUT_REGIONS=x100y100w200h250,x0y0w500h500` The first argument applies to Display 1 and the second to Display 2. You can specify additional regions for any other displays, if required. ## Additional resources * [Build and deliver for Embedded Linux](/engine/6000.7/manual/platform-specific/embedded-systems/embedded-linux/build-and-deliver.md)