 Okay, so hi everybody. I'm Luca Ciazzoli and I'm talking about how Linux can run on the ZNKP processor by Xilinx, especially in the ways that it differs from other system on chips. I work as an embedded Linux engineer at IAM Sportline, designing the next generation data loggers, dashboards and action cameras for racing. I also love open source, of course, and I contribute to some projects including build-root. Okay, so I will first give you a brief introduction about the chip itself and then proceed to which development tools are available, how Linux can use your FPGA design and how to boot this thing. And then there are a few shorter sections about using the GPU and the video codec unit. Basically, the ZNKP is a so-called soft-class FPGA, so it is a system on chip, pretty much like many others, but it also has a piece of FPGA which is directly connected to the processor on chip, which makes it very efficient with respect to other architectures where the FPGA is connected externally or the CPU is synthesized on the FPGA itself. If you are new to the topic, there is a good introduction by Marek Vashut. This talk is an overview of the topic which is quite good. Okay, basically the two main vendors for this kind of thing are Xilinx and Altera, which is now Intel. And I'll be talking about the current second generation by Xilinx, which is the ZNKUldro scale plus MP SoC, but people call it ZNKMP because it's shorter. There is a previous family generation of SoCs, which is a ZNK7000, which is now pretty much well established. Intel has a pretty similar set of two generation of processors, but I don't know much about them. Okay, this is the block diagram of the system on chip. As you can see, it has, well, in its most complete versions, it has quad-core ARM64-bit processor A53, two real-time cores. It also has the usual long list of peripherals for system on chips. Most of them are connected to a low-power interconnect. A few of the faster peripherals are on the full-power interconnects. Okay, then there is also a GPU in some versions. There is, of course, a digital controller. There are two specialized units, the CSU and the PNU, that are involved in booting, so I will talk about them later. It also has a video codec unit, which is a video encoder and decoder in hardware, and some other very fast peripherals that I'm not talking about. And then there is, of course, the FPGA, which makes this design quite peculiar. Okay, so to develop on this kind of processor, of course, first of all, you need documentation. There is a lot of good documentation, generally quite good by Xilinx. It's accessible on that pretty long URL on their website. There you find a few dozen documents of general interest about the platform, and then there is much more. Okay, then starting bottom-up, you design your FPGA. This is not the subject of this talk, but anyway, just briefly, the tool that Xilinx provides for this is the Vivado Design Suite, which includes Vivado itself, which is the thing you used to design FPGA down to the bitstream, which gets downloaded into FPGA. And then there is the XSDKE, Xilinx SDK, which is an Eclipse IDE to build firmer bare metal software for the Xilinx processors. All of this runs quite okay in Linux, and there is also a zero-cost version. It's all license-based, so it's not really completely free, but the zero-cost version has most of the features, but not the most advanced ones. Okay, so it's quite useful. It does a lot of things. However, it is closed-source. It is a very huge software to install. You have to have a pretty powerful computer to use it. It also has some bugs and annoyances that people complain about, but of course it's closed-source, so you can't do much about that. But it's generally a good product, but you might wonder whether you can use some open-source alternative. You're not that lucky, because today it is not possible to use a fully open-source tool chain for this kind of FPGA. Although there is a reverse-engineering effort in progress, it's called the Simiflow project. It's in quite an early stage for the Zinc 7000 platform, so for Zinc MP it's probably very soon now to expect something, but it's good that this thing exists. Okay, here is an interesting link on other reasons why you might want an open-source tool chain. When you have your FPGA working, you need to build the software on top of it. Of course, the two main pillars of the BSP to support the processor are Linux and Uboot. About Uboot, Xilinx is quite active in working on the mainline Uboot to support their own processors, which is very good. I think it's supposed to be ready to boot Zinc MP processors in Uboot mainline. Although I haven't tested that because it doesn't support the board I have, but there is also some additional development that you can find in the Xilinx GitHub repo. They have their own Uboot fork with things that are not yet in mainline, so you may want to look at that if you need something, a board or a feature that is not yet in the mainline. Okay, the other big pieces of Xilinx kernel and the situation is quite similar, so Xilinx is contributing to that as well, although I think they are a lot more behind, so I think it's quite incomplete so far. So you might probably want to have a look at the Xilinx fork on GitHub. The current branch from Xilinx has started like 20 years ago, so it's diverging a lot from mainline, but from time to time they start a new branch, somewhat like once per year probably, not official, so there might be a new branch being published soon from a recent kernel. The one that's now in use is a branch from kernel 4.9. Okay, and on the Xilinx branches you can find both development for the hard silicon features that are specific to Zinc and P and to the IP blocks that you can put in a PGA and that are new in the Zinc and P that were not existing before, especially related to video processing. Okay, and finally you need to build the whole system, and in this respect you have to make a choice about the workflow that you want to use because there are at least two main possibilities. I've called them the Xilinx workflow and the community workflow. The first is the one that Xilinx supports and documents in their own reference designs and the second is developed by the community with some support by Xilinx also and it is closer to how other open source development works in other vendor system chips. Of course you can somewhat mix and change on this, but these are the two that are in most common use as far as I know. Right, the Xilinx workflow involves of course using Vivado and XSDK for the FPGA and the bootloaders and low level stuff and then they use Petalinx as a build system which is a Xilinx specific build system. It used to be a build system on its own, different from other things. Nowadays it uses EOcto internally so it's got a middle standard although if you use Petalinx directly you don't see EOcto working but it's there somewhere in some of its sub-directories so you can have a look at how it builds things and which recipes it used. It uses actually those three layers mainly so in case you want to have a look they are on GitHub anyway. And the other workflow, the community workflow also involves using Vivado because it's currently the only tool that you can use to design the FPGA and also a little bit of XSDK, I will talk about that later. And then there is one layer, the MetaXilinx BSP layer which is developed quite in line with the standard for a EOcto project and as well as a general BSP for any system on chip. All right, but this does not support yet all of the features but it's already quite complete now. Okay, a couple other useful resources. There is the MetaXilinx mailing list which is mostly to discuss the Xilinx-related layers but it is also a place for general discussion about the usage of Linux on Xilinx hardware in general so it's useful for many users. It's low traffic so you can follow it easily and also there is this layer MetaTopic which is just support boards made by a manufacturer called TopicEmbedded but it has some useful code that I used that is not found on other layers. Okay, there is no currently support for the Zinc and P in build route but it's work in progress. The first base set on the mailing list is to add basic support from one board and it will evolve to probably support it in the next few weeks or months. Okay, so let's see now when you design your FPGA how you can run it on Linux. Okay, the very interesting thing that I found very cool about this kind of chip is that you can basically design your own system on chip. That's because the FPGA is connected to the CPU via AXI 4 buses. AXI 4 is part of the AMBA specification by ARM so it's the same kind of buses that is used inside the system on chip to connect the processor to the peripherals and so it follows the same standard. You can access the registers in an IP block in FPGA just like you access the registers on an IP block in Cinecon and so it actually becomes like a system of chip that you design in part. Okay, the steps when using Vivado are mainly three. IP integration, address editor and constraints. The first step, IP integration, it takes place in this window, the block design editor. You can't read that, that's okay. It's blocks connected by lines, basically oversimplifying the electronic circuit. Each of these blocks gets synthesized into FPGA and with some exceptions, the block one here with Zinc Ultrascade written on top of it does actually represent everything that is on the chip outside the FPGA. It's there just because this view is FPGA centric. That is there because you can double-click on it and customize it so you can customize how you want the hard silicon part to work. You can configure the PLS, the power domains, the various peripherals, buses and so on. And this results in a configuration file that gets saved which actually sets a long list of registers into the various peripherals. If you double-click on other blocks, such as for example a GPIO block, you can customize that one as well, in this case it will change what will be synthesized in the FPGA. For example, you can say for this GPIO block you only want three pins, not 32, because you need only three, so you optimize the usage of your FPGA. You want only inputs and you cannot set output because you don't care and you want to have an interrupt, you want an interrupt line. So in this case you will have a customized hardware. And when you synthesize that in FPGA you need to put it on Linux. So there is a wiki page by Xilinx which lists all of the devices that can be presented either in silicon or in FPGA and how to use them. So it points to which is the Linux driver and there's some documentation of it and in the Linux kernel the device tree bindings are documented so you can write your own device tree snippet to support this block and it's nothing but a GPIO controller with its own compatible string that you get from the documentation but you also have to say sometimes several parameters to tell to Linux how the hardware has been synthesized so you have to tell it it has three pins, they are all inputs it has interrupts or they are all outputs and so on. Otherwise the operating system will try to access registers that are not implemented or generally to use features that are not there and this will result in crashes. It's very important that you keep in sync your FPGA bit stream with your device tree. It's very easy to like update one and not the other and then everything crashes so you have to pay a lot of attention to this. Okay, so interrupts are managed this way the non-fpga part can have up to two interrupt ports each of eight bits and you can connect it this line here comes from the GPIO block you've seen before and so it will end up in one of these things here and this entering the hard silicon part and this is connected to the geek so the main intra controller in the ARM core and so this is how you do it in Vivado and you configure it in Linux in a very standard way so you have intra parent is the geek unless you have an additional intra controller outside of course and you have interrupts we take three parameters so we say the type of interrupt but the most important is this one which is the interrupt number to know which is the interrupt number you have to add your offset here to the base number which is somewhat hard to find you have to look here and there to find it but luckily there is a file that has the fines for them so I think this is 96 or so unfortunately the fine file that the DTSH file that defines this one is not in the kernel sources but on this other repository here so I copied it immediately in my kernel and it's very useful ok, next step in Vivado is the address editor whenever you add a block that is accessible via an interconnect it will add a mapping in the address map for that block so this is all done automatically and for the GPIO block it will be accessible at address A00 blah blah blah this is something that you can change if you want and then this is the number that you have to put in device tree so in your reg keyword you have to put this address here and the width which is in most cases 64 bits and that's it so that gets very standard again you have to keep them in sync your bit stream your device stream has been in sync or everything can happen the third step is to define the constraints for each of the nets basically the lines in your FPG design that go outside the chip you have to define to which pin they map the IO standard whether they have a pull up or pull down the similar things but this is not this doesn't affect the Linux part because it is not related to the software but rather to the outside of the chip that will impact here on the kernel okay that's all for the Linux configuration it's pretty standard if you pay attention to keeping things in sync and the next big step is you have to boot it well actually it's the previous step but I put it in this place okay back at the good old times with simpler system chips you just had to load an SPL from storage to internal RAM that initialized RAM and loaded the big boot loader which loaded the kernel in AMP64 it's a lot more complex of course and one of the items that are involved is the platform management unit the PMU thing which is here which is a processor that is responsible to do all power gating and con gating which is very very important for the system to run you cannot boot without its intervention because it has to enable the devices you need this design is somewhat similar to many other ARM64 boards it's rather complex but you have to handle this it's mandatory and okay another unit involved is the CSUD configuration and security unit I think and so first about the PMU the PMU is actually a micro-braze processor so it's a small micro-controller basically which can execute a firmware that you can program but in the practice you must reprogram it if you want to boot both U-boot and Linux require a PMU firmware that is more recent than the one in some Silicon and so you have to reprogram that luckily the source code has been made public by Xilinx it's actually a permissive license but with the restriction to execute only on Xilinx hardware but anywhere the sources are there you can work on them and there is a recipe in the master branch to build it in order to build it it first builds an entire micro-blaze tool chain with newlib it will end up in a firmware build for you okay and the PMU firmware does not run on its own it also needs a configuration object it basically tells which master owns which slave where masters are more or less the CPUs and the slaves are the peripherals so that's just to avoid that both the Cortex A53 and the R5 or another processor synthesizing FPGA request the same peripheral and this wouldn't work of course this configuration depends on how you configure things in the big window where you configure the hard silicon block so there is a configuration file generated for that another big component you need for booting is ARM trusted firmware you need it on I think every ARM 64 architecture and what it does is it answers to you boot or the kernel or whatever is in the less privileged execution level it replies to SMC calls this is just ARM standard and this calls alone for example to enable devices and so on but actually ARM trusted firmware does not do the job really but forward this request to the PMU using exciting specific API so you need both of them and when for example you boot or the kernel tries to enable a device it will ask ATF which in turn asks to PMU and then the device gets enabled okay two workflows as I mentioned earlier and there are two boot flows also so if you're using the Xilinx workflow you are guided to use this boot flow where there are mainly three actors the PMU the CSU and one of the processors for example the A53 but it could be the R5 as well okay so when the PMU wakes up and all it does is wake up the CSU the first stage boot loader is exciting specific into memory to be executed by the A53 processor for example and it also loads the PMU firmware inside the PMU so it is where the PMU firmware gets updated during boot right and it also loads from the boot medium the configuration object and send it to the PMU and then ATF and Uboot so this way Uboot can really start and go through ATF and PMU to do all of its stuff so it's quite complex okay and in order to build the pieces you have to go through you start from Vivado with your HDL design your FPGA design and it produces an HDF file which means hardware description file which in turn you use to open the Xilinx SDK and based on how you configure the hardware it has wizards to produce a PMU firmware a first stage boot loader each with its own BSP it's all done via wizard so it's very easy and in the end they will produce the two binaries for the PMU firmware and the FSBL also the FSBL BSP is the place where this file PMConfigurationObject.c will be created it is the configuration object to be fed to the PMU so as you can see it's in the FSBL so it's an FSBL that owns this configuration alright the Linux actually via internal EOPTO rules will build ARM trusted firmware new boot and all of these along with the bitstream for the FPGA is fed to the bootgen tool which will produce the boot.bin file boot.bin is the big file with all of the things that happen in boot before the Linux kernel basically and it is put on your boot media for example in the SD card the hardware the wrong loader which is executed by the CSU will load from the boot.bin only PMU firmware and FSBL and then FSBL will open the file again and extract all of the rest to put them in memory or in FPGA so that's the build flow with the Xilinx workflow these are some advantages it's supported of course the Xilinx tools make it easy with wizards and clicks and also the FSBL code is very simple it's simple to understand how it works so if you want to understand what's going on but on the other hand it's not optimized so it's super slow for example to load a relatively small FPGA it takes like 3 seconds which could be optimized a lot also the Xilinx tools have the requirement especially if you have continuous integration you have to install them and then they are hard to automate so it is a little bit cumbersome to use in some cases and also the proprietary bootgen tool is needed to generate the bootbin with all of this stuff and finally this flow is completely different from other version flows that you probably used on other vendor stocks so let's see what's the alternative that the community has come up with this one is the core of this alternative is that we have to replace the first stage bootloader with something else because the first stage bootloader needs a bootbin produced with the Xilinx specific tools and so we want to replace FSBL for performance and for this reason the obvious replacement is Ubud SPL which does a very similar thing but there are a few obstacles to this first is that Ubud SPL cannot load the FPGA like the FSBL does this is not an issue however because Ubud can load it and it's also a lot faster than the FSBL but 10 times faster because it's optimized the second issue is that the Ubud FSBL loads Ubud not arm trusted firmware so various architecture have various ways to achieve that and in this case there's a trick to achieve that and finally Ubud SPL cannot load the PMU firmware configuration object so we'll get to the second and third point now to load arm trusted firmware the thing is Ubud needs ATF so SPL must load both for Ubud to be able to run and what happens is there is a trick to do this which is in all the ZincMP that configs Falcon mode is enabled in SPL Falcon mode which is meant to achieve higher boot speed than with regular Ubud so what it does is SPL loads directly the kernel and the device tree in RAM and jumps to the kernel completely bypassing Ubud to speed up the boot but in this case it is configured in such a way that the DTB image is called Ubud.bin and the kernel image is called arm trusted firmware Ubud.ub so it thinks it is loading kernel plus DTB but in the practice it is loading Ubud and ATF so this approach works this approach works but you lose the possibility to use Falcon mode to really speed up the boot because you've already hijacked it for something else and okay it's a bit of a hack but at least it solved for us one of the problems the other big problem is the configuration object must be loaded into the PMU firmware for it to work but there is no code in SPL to do it first because nobody wrote it second because of license conflict and so what happens is there is workaround it is the best workaround that I know of at the moment which is you take the PMU configuration object as produced by XSDK and put link it directly into the PMU firmware and then modify the PMU firmware to load it directly at startup so it's hard-coded inside the PMU firmware it's very simple it comes from the metatopic layer that I mentioned before it's not in mainline not at the moment at least I mean not in the mainline metaxining it might be in the future okay since understanding how all of this thing was a bit complex and took a lot of time I wrote a very trivial script that does the very minimum needed it's in this repository it does only three things take Rostrom NG to build a micro-bracetool chain patch the PMU firmware sources and build it so it's easy to understand how the PMU firmware gets built and it allows to use it without having to set up all of the yacht machinery and rules to do it so this approach works which is good on the other hand it forces you to rebuild the PMU firmware every time you change your configuration in the core things but anyway you would have to rebuild the FSBL with XSDK so it's not very much different and the boot sequence with the community workflow becomes this one it is very similar to the other one but the differences are SPL is loaded instead of the FSBL so it's just another piece of code with similar things and the configuration object is not loaded by the SPL it's hard-coded directly in the PMU firmware the rest is all identical okay but that's another example we also need something else because what you do in Vivado you configure lots of devices in all of these hard silicon parts and that results not only in the PMU firmware configuration object but also in a file that is called PSU in ETGPL well two files that you can download and these need to be applied it's basically a long list of register settings so it sets a bunch of registers to set pinmuxes, PLL speeds and the SD run controller and so on this file can be obtained this way when you done your design with Vivado you can just do file export, export hardware to the HDF file which is actually a zip file you extract it and you get these two files you put them in the UBOOT sources in this directory you also have to make sure that those are built and not the other ones that UBOOT has for some boards and so that's it when you're done with that you have a UBOOT that UBOOT will set all of those registers and they will work but you have to launch the whole xsdk manually to produce a file just to obtain a single .c file but the rest of the build process is well maybe a little simpler so it starts in the same way with Vivado producing the HDF file and from that you can launch the xsdk which you only use to launch the wizard, produce the fsvl vsp and take the pm configuration object .c file .c is missing from there and that's it, then you can throw away everything produced by xsdk and the build process is entirely done by Yocto in this case and it will be the quite standard arm-tested firmware and UBOOT along with its micro-basicum chain which links the pmu configuration object and finally the UBOOT rules can produce the UBOOT proper the SPL and then they can produce a minimal boot.bin that only contains the SPL and the UBOOT SPL and the pmu firmware itself it doesn't contain all of the other pieces and it doesn't do fancy features just like encryption and similar so it's very minimal to this use case in the end you have just to put on your boot medium all of those files because the other files are accessed by SPL and that's it, so in this way you can have a complete build which boots and works with this one of the two main approaches so that's it for booting the next chapter is about the GPU this system chief has a GPU which is very interesting makes it very very interesting but the CPU is an Armali 400 which is very sad because it has very bad support I think it's luckily the in in terms of software support that's because it requires a binary blob which makes things always a little bit complex and annoying so basically that's the only option although there are two open source alternatives one is the the Lima driver, the reverse engineering project that has done a lot of the reverse engineering work but has never reached real usability for complete projects and is now abandoned I think the other is the Mesa Lima project it is quite a new project started I think last year and it's advancing not super fast but steadily and so it may be that at some point we have an open source driver for this for this GPU at the moment I think it's ready just for some simple rendering not yet ready for complex applications so let's see how you do things in the only possible way so you have to use two components there's a kernel driver which is GPL but it's not in many lines one of the issues with this driver is it does not much actually all of the real work is in the user space library all the interesting stuff is done in the user space library which is the binary block that you have to use and which implements the OpenGL APIs so every other application is based on top of that also this library is SOC specific so you cannot reuse the library from other processors so you have to use the one from Sightings to build the two components the kernel module is fairly simple there is a Yoctorecipe on the MIT Accidings BSP which just downloads the source with ARM and applies 10 patches and then it builds just fine I haven't looked into detail into it because it worked at the first attempt the other part is the user space library which is more complex first of all you have to find it it's not in the main master branch for MIT Accidings BSP it is only in the Sightings fork which is on GitHub so if you want to stay on the master branch working on that you can just take the recipe from the the most recent is the real v2017.4 layer you take the recipe from there copy it from layer and that's okay should work without any modifications now that you have your recipe you run it and it fails because it cannot download the sources in fact the URL to download the sources is from this domain which is not accessible it appears to be an internal repository for Sightings so you cannot download from that so you go into the documentation and there is a readme file along with the recipe and it tells you have to register on the exciting website, download the tarbol and open the tarbol there is some instructions and a second tarbol and then you have to extract the second tarbol in which contains the third tarbol and that's all there are only three we are almost finished and the third tarbol when you extract it it looks like a bear gate ripple and in fact it is it is basically the thing that big downloads in the download directory it probably has been taken as put in a tarbol, in a few tarbols and then you have to put it in some random directory that you want and point source mirror URL in your local account to this path so that you can find it as if it had downloaded it and then things will work so a slight simplification on this well I basically wrote a stupid script to do all of these steps because you have to redo it whenever you want to upgrade the library or whenever you want to trap a new development machine but I also chose to extract it in the main download there for BitBake so at least keep the last step and leave source mirror URL for what it's made for when you're done with that you can use it in two ways because there are actually two different libraries one is to use with FBDef with good old frame buffer and the other with X11 okay the frame buffer version actually works for normal needs of many embedded systems like running a QT or QML application on a single screen it works but forget multi-screen it doesn't work apparently there is slash def slash FB0 hard-coded in the library so you cannot use more than one screen so we tried X11 the X11 version but we couldn't make multi-screen work with that one as well not sure why exactly but QML with a software renderer works fine with multi-screen while the accelerated one does not work so I don't know exactly about that but that's it at least waiting for an open source alternative and that's all for the GPU and let's go to the video for the QNIT this is a little better in terms of support luckily so what happens here is there is this video called the QNIT which is an H264 and H265 in hardware it's able to do 4K at 60fps so it's quite powerful the interesting thing it is not connected to an interconnect it is floating in the middle of the FPGA so you have to wire it inside the FPGA to use it which I think makes it a little bit more flexible anyway this is not a big deal it's quite fast to do and this is the whole stack to use it from starting bottom up there's the VCU itself which needs a firmware which is a binary blob from Xilinx then you have a kernel driver you have a user space library and an implementation layer for OpenMax all of these three are provided by Xilinx with sources with the same license which is permissive but restricted to Xilinx hardware okay and then well OpenMax as far as I know is implementing APIs to interface to a codec so you can use it directly probably but most common usage is to use Gstreamer as an OpenMax plugin so you can just put an OpenMax X264 encoder in your Gstreamer pipeline okay so to instantiate the VCU you have to put a block in Vivado just like the Zinc and P block it's not really being synthesized in FPGA but it represents how it should be connected to the rest of the world and then you have to set up a device tree entry in Linux which is standard nothing special here okay and then you have to set up all of the software all of the software is only in the MetaPetalinx layer not in the MetaXilinx BSP layer which is a layer that you are not supposed to use with the workflow so I tried to use this layer just to have the VCU support and I've lost a few days in beating my head and after all I understood it was better not to do it the reason is that well I'm using Yachto24 which ships Gstreamer 112 while MetaPetalinx has BBappens to change that to Gstreamer 1.8 but then it tries to apply patches that it does not ship so it expects them to be in the popular layer but they are not there anymore so it won't be but there is a much simpler solution that is don't use the Petalinx layer just take from the MetaPetalinx layer these four rules unmodified which are the kernel module, the firmware the user space library and the openmax integration take themesis and then take this BBappen file from the same layer which is for Gstreamer OMX so it tweaks the openmax module of Gstreamers to switch to the Xilinx fork which is different from upstream and apply some build flags to customize it for Xilinx and then finally you can install Gstreamer 1.0 and that's it nothing more it builds and it works you can write a pipeline that includes H.265 or H.264 and so on and I didn't test it extensively but for a few tests it works fine that's it just to draw some conclusion as you probably understood this chip is very powerful and very flexible but it's also very complex and the same thing applies to software also software support is complex to set up but if you know where to go and find the appropriate pieces you can set it up also Xilinx is providing their support currently mostly out of mainline but they are working in mainline at the moment I think they are a bit slow in that probably because they want to set up everything in their own branches first but they are slowly moving which is very good and they are also putting an effort in using standard tools which is promising for the future also that's all hope that was not boring too much any questions? yes? can you speak louder? the question is if I consider for ATF loading using the fit image which is used in other platforms the answer is no I didn't consider it because this approach is the one that has been implemented by other users of this platform or by maintainers of this platform it was already almost ready to do but I think fit could make some improvement SPL can load fit I guess ok I don't sorry? ok, yeah right, so Rockchip is using the fit image probably others I agree with you at first sight that this seems a better approach I don't know if there are reasons it has been done in another way ok, yeah I don't know why it hasn't been done that way sorry any more questions? yep I will dip you well and support I don't know I'm not using it sorry ok, so the thing is using X11 that's actually main copies of buffered refuse windows but in fullscreen it does not actually in fact I used it only in fullscreen but it didn't give any improvements in features over the fb def so I stayed with the simple fb def X11 for fullscreen seems like fb def to the user so it's simpler ok, that's all thank you very much