Published on 2018-03-04 in
Hardware Design
One of the great feature that comes along with ADS Package is the ability to create your design in a reverse flow. This necessity become more evident when you prefer to use other feature-reach layout tool than ADS and use ODB++ or ADFI tools afterward to import the design into the ADS for performing layout verification. In this tutorial I will summarize multitude of notes that you should consider to get a successful schematic back from your designed layout.
To start, first convert the traces into microstrip transmission line by right clicking on a trace and select Path/Trace > Convert Traces
. If you were lucky the trace would change to microstrip type without any significance change in the trace color but if that’s not the case, you’ll notice changes in trace appearance like becoming invisible or transportation into a wrong layer. This is illustrated in Fig. 1 that shows a transformation nullify the line due to the fact that new wrong layer is an outline
type. To solve the issue, proceed to the following steps. In case you hadn’t counter to the mentioned problem you can skip following steps abd generate schematic directly by Schematic > Generate/Update Schematic
in the layout window.
Fig. 1. Transform the trace to microstrip will change the layer unwillingly
1. Remove Ports
ADS sometimes have issues with ports and terms. So if you cannot generate schematic from the layout it is probably the main cause.
2. Substrate File
After generating schematic you’ll notice unconnected components placed vertically on the canvas. If you rearrange the components you get something like Fig 2 which by now you were recognized that ADS failed to import the connectivity back into the schematic. Unfortunately there is no automated fixation for this issue, which leaves you with no option but to make the connections manually. After that from the Parts
panel, add a MSub
component into the canvas. Now if you checkout files in your workspace you witness a new file named tech.subst
. This file is a auto-generated stackup file that in many cases may contain some errors so it it recommended to to compare new generated substrate file with your current stackup and apply the required changes.
3. Configure Microstrip Layer
The last step is to configure the layer that microstrip will land on. To do so, double click on MSub
component and adjust Cond1
parameter. Cond2 is, ADS said and I quote
Layer on which the air bridges will be draws
Probably the ground layer but still I have a doubt about that. Finally by selecting Layout > Generate/Update Layout
in the schematic window regenerate the layout.
Cheers!
Published on 2018-02-08 in
Hardware Design
Understanding the math behind length matching of each protocol is a key in reaching out a well designed PCB with a balance between performance and layout area and other manufacturing constraints. Unfortunately for some protocols such as SDIO these information remained under NDA’s and are confidential. Here I examined ZC702 reference design board and/or datasheet of the PHY chip or the ZYNQ UG933 for figuring out the knowledge behind the design.
SDIO
As I mentioned above, SDIO full specification isn’t at disposal of the public, nevertheless by examining the ZC702 traces delay and inspecting constraint manger of the board I finally grasp the situation. The ZC702 configuration simplified by the following diagram. Also under the diagram you can find out each traces delay, from ZYNQ AP-SoC chip to TI voltage translator and ended to SD Card connector. Delay for the CLK trace from U1 to U87 is a cummolative sum of U1 to R81 delay and R81 to U87, this is done by defining R81 ESpice model and creating an XNet in the Allegro SI Analysis.
From the SDIO specification, for proper High Speed Mode
operation, the CLK line shoud be 1ns
longer than CMD
and DAT[0:3]
. Furthuremore CMD
and DAT[0:3]
should reamin in a 50ps
margin from each other which is a tight version of what UG933 recommended:
PCB and package delay skew for SD_DAT[0:3] and SD_CMD relative to SD_CLK
must be between 50–200 ps
But by inspecting following table which is extracted from ZC702 board you can conclude that all lines are matched together without any sign of 1ns
delays on the CLK
line.
After checking out TXS02612 datasheet, you can see on page 12 the clock to channel skew is roughly around 1.5ns which can justify why the clk traces has the same length as other signals on the PCB.
RGMII
The Reduced Gigabit Media Independent Interface or RGMII is an low pin count interface between the PHY chip and the controller. Ethernet protocol is instinctivly a Full-Duplex non-synced protocol, thus the TX and RX signals are completely independent. Differential traces from RJ45 back to the PHY chip are completely independent and only the phase matching in a differtial couple should be considered. For the RGMII signals, the mathing requirments is highly depends on version of RGMII that PHY chip supports. Here we assume a conformal with RGMII v2 without internal delays. In this case following traces in each group should length mathed to the margin of up to 100 ps
with each other including ZYNQ package delay.
- TX Group:
TX_DATA[0:3], TX_CTL
- RX Group:
RX_DATA[0:3], RX_CTL
The average delay of each group should be length mathched to corresponding CLK with a delay of 1.5ns
shorter. MDIO and MDC are operating at max frequency of 2.5MHz thus doesn’t require any length mathing. Any other signal that does not mentioned can routed at any arbitary length.
Useful Links
Xilinx – AR# 59999: Design Advisory for Zynq-7000 SoC, eMMC – JEDEC standard
Texas Instruments – TXS02612: XS02612 SDIO Port Expander With Voltage-Level Translation
IEEE 802 – Specification Gaps and Improvement of MDC/ MDIO Interface
Published on 2018-01-18 in
Hardware Design
I know that there exist many disperse app note around how to export pin delay and why you should do that nevertheless I can’t find any comprehensive guide line which accompany you from A to Z of this process so I convinced to wrote down this post. For DDR3 and other sensitive high speed signals it is recommended to do the length matching with taking account package delay. This requirement only applied for non high-volume custom designed chips like Xilinx FPGA and other SoC’s available on market, in other word well-establish ICs like DDR chips pin delay’s had already been matched internally.
Export Pin Delay
1. Open Vivado (my version is 2017.2)
2. On the TCL command window execute following commands
link_design -part xc7z020clg484-3
write_csv pin_delay.csv
Prepare CSV File
Unfortunately output file of Vivado not work out of the box. You need to open the CSV file in some text editor (I use one of the most primitive one, Microsoft Excel) and remove the trivia rows and columns from it. Next thing is that Vivado export package delay in terms of Max Delay
and Min Delay
but Allegro only support Pin Delay. So you have to choose between the two or doing some math and get an average.
1. Remove all rows until only pins or banks remain without any empty row or heading
2. Remove all columns except Pin Name (like A9) and one of Max Delay
or Min Delay
3. Add Unit. Vivado output delay in ps unit but allegro may not compromise with this choice. To overcome this issue, you need to add ps
to the end of all delay values. In Microsoft Excel in a new column (we assume C is new column and delay values are in column B) write formula =B1&" ps"
4. get gripper from bottom corner of cell and drag it all the way down
5. copy column C and press Alt+E
, S
, V
to paste special into B column. (I hate Excel, use bash+sed)
6. save file into a CSV file and open Allegro
Import To Allegro
1. Go to File > Import > Pin Delay
, select CSV file and click on your chip.
2. Pick Import button and close the Pin Delay form.
Published on 2018-01-15 in
Hardware Design
Inserting via in RF and Microwave regions might seems to be a scary thing to do but as revealed through EM simulation for low portion of Microwave frequencies (below 10GHz) using a full via isn’t as worse as it seems to be. From “full via” I mean a via that start from top layer and end in bottom layer, using a partial via (that end or start on layers other than top or bottom) will results in considerable amount of reflection and poor S11.
In order to find out a perfect transition from the top layer to the bottom layer , I use ADS Via Designer tool, to sweep on all available parameters. I ran parameter sweep on Drill Diameter, Anti-Pad diameter and pad size. I used a simplified stackup shown below which is a typical stackup in may RF boards, two layers of 8mils RO4003 substrate around a FR4 prepreg.
Overall Geometry
One of the main concerns regarding designing a perfect Via structure is being careful about return current path. In the case of my design, because I used GCPW (grounded coplanar waveguide) a rectangular via stitching may integrate more naturally to the board, albeit a two horizontal may work out too. On of the first concern in selecting right via stitching is distance of vias. Through long simulations I figure out that the perfect result will achieve when you place transition via stitching in the same position as the stitching vias you used to construct your GCPW.
In the following design with 17mils trace width and GND guard of 16 mils from each edge of transmission line, a via stitching with 100mils distance between center-to-center of via works the best.
Note: dx
and dy
in ADS Via Designer are distances from the TL not from the corresponding via.
Optimizing Parameters
For the TL via, three degree of freedom are available but from manufacturing and physical point of view some of these values may not be practical. drill size
is the most constrained parameter that restricted to both available bit size and the free space that is available on the board. After playing around these three parameters, it seems that no matter what value you choose for your drill size, there is always some pad size
and anti-pad value
that compensate drill size
. For the pad size
and anti-pad value
you are limited only by the clearance value of your PCB manufacturer. For both of these value a step size of 1 mils seems to be fair. In my case I use a 0.3mm (12mils) drill size, and because of 4mils clearance the anti-pad diameter should be equal or bigger than 20mils.
Results
After running a lengthy sweep on via ring size and antipad diameter, it revealed that at 0.3mm drill size, the via structure shows more inductance than capacitance. To reach a perfect wideband 50Ohm characteristic impedance, adding more capacitance to the structure was a must. In compliance with simulation results, best performance achieved when via ring is large enough and antipad is shorten to it’s minimum values. In my case the final choice was 0.3mm drill size, 27mm as the diameter of via pad and 8mils(min clearance)+12mils(drill size)=20mils for antipad diameter. The thicker green line at bottom is the S11 of chosen via.
Final Notes
To conclude this post, we saw that at small drill sizes, DFM rules prevent to reach a decent performance. Small drill sizes results in higher inductance that need to be compensated by tight GND coupling and large via pad. To surpass this drill sizes can be choose to be bigger resulting in lower inductance and relieving capacitance requirement. Designing a via at low frequencies (sub 6GHz) isn’t a challenging problem but getting an invisible via from EM point, can be a big thumbs up work to do, moreover same rules and workflow can be applied at more critical frequencies to achieve better performances.
Published on 2017-11-15 in
Hardware Design
ADS Momentum is a full-wave EM field solver that merged with ADS package for more than 10 years. Starting with the ADS 2016.1, two new tools introduced by Keysight, the SI and PI Pro environment that can be accessed through layout interface inside the ADS software. In this post, I’ll talk about features of these two new tools and the reasons behind why they become an essential tool in the first place.
ADS Momentum
Momentum is a 3D EM solver. Have both RF and microwave options available. RF Mode solve EM fields in a simplified environment by utilizing approximated formulas while Microwave Mode use the full-blown Maxwell equations to solve the fields. Aside from accurate results that Momentum provide, this tools is memory and cpu-time hungry. If you try to simulate a simple two layer 6cmx6cm PCB with this tool, the process may take a day with consuming up to 80GB of memory to be solve. This is not a unexpected situation, because solving a board inside Momentum, make this tool to mesh all via, traces and planes in a full 3D environment. Momentum then solve the EM in a 3D box and calculate cross talk between all traces across the board even if they are completely isolated from each other.
In these cases if you don’t access to a superior machine, you will have to cutting out your design and simplify it as far as you could. This process is tedious and may take you further from achieving accurate results. This problem originated from not simplifying the design in a smart way and ignore the fact that we are surly simulating a PCB with focus on coupling and signal integrity. Thus far-field calculation is absolutely trivial.
ADS SI/PI Pro
To solve the discussed issue, Keysight developed a new EM solver engine that consider PCB requirement in mind. SI/PI Pro accelerate the simulating process 10 times by exploiting the special conditions that applied to PCB designs and RF boards that simplify the design. Although this simplification will results in less accurate simulation, it is a complete automated process with zero overhead and the boost in the simulation time is much greater than manual simplification that you can do in the Momentum.
Fig 1. PNA6 pcb imported to ADS SI Pro
Comparisons
To evaluate the solvers, I imported PNA6 design into both Momentum and SI Pro environment. Then in momentum in order to cutback the cpu-time, I had to remove non-related layers, remove GND plane coppers and replace the layer with a slot plane, then optimize the Physical Model tab inside the EMPro options and finally remove superfluous traces from the layout. Carring out these preparation steps takes me almost 30 to 45 minutes which is quite long if you had to change the layout in Allegro and redo the whole process.
The simulation performed on 100MHz to 6GHz on a 4 layer RO4003 substrate. both Momentum RF and Momentum Microwave results in a same S-Parameter with slightly negligible differences in high frequency portion. The SI Pro results also compromises with Momentum although it shows some difficulty in achieving accurate S-Param the results are in complete compliance with momentum results and simulation process is so much faster than Momentum.
To conclude this discussion SI Pro shows a good fidelity toward achieving good results and as long as you can neglect 1 or 2dB errors the reults could be enough for you. Si Pro neither care for far field calculation nor can be used to simulate Antenna design but as far as your designs are limited to PCB or chip layout, SI Pro can serve as a nice companion toward reaching your goals in the product development process.
Useful Links
1. YouTube – Passive Circuit DesignGuide with a Momentum Simulation
2. YouTube – SIPro Introduction
Published on 2017-09-23 in
Hardware Design
Cadence and Keysight are collaborating with each other since 2000’s which brings one of unprecedented feature to reality, an ability to export your design from allegro to ADS seamlessly. In this tutorial I will demonstrate how to configure Allegro Design Flow Integration (ADFI) for Allgero 17.2 and ADS 2017 Update 1. I am aware that for ADSs prior to the 2016 version, there exists some compatibility issues with exporting from 17.2 version which is caused by some updates in Allegro SKILL engine, thus it is recommended to use the 2016 version or later.
Configuring Allegro
To configure ADFI in Allegro you have two options, one, If you had installed Allegro alongside ADS on the same machine then you are already good to go, but if you have each software on a separate workstation you need to install Python 2 before going any further. I’m using 2.7 version and it works with Allegro 17.2 flawlessly. Follow these steps to configure ADFI:
- Open Allegro, from menu select
File > Script
- In the opened dialog click on Browse button, check the
Change Directory
checkbox and open
<ADS_FOLDER>\ial\scripts\eemLocalConfig.scr
- Click
Replay
button to run the script
- Select “Integrate with ADS” if you have ADS installed and “Standalone” if not. In case of “Standalone” browse to the path of python.
- Click on
setup
and Restart the Allegro
If you did the steps correctly a item named Export To ADS/EMPro
will show up in menu bar.
Generate ADFI File From The Board
To export you need to select the nets of interest prior to export. To do that
- From
Export To ADS/EMPro
select Select Traces
item.
- Select the nets, layers and then go to
Cookie Cutter
tab. In this tab you will create a board cutout geometry.
- The process is nearly straightforward. the cutout can be generated exactly around your selected signals in the
Trace Select
tab or be loosely wrap selected trace. This will be determined by the Initial shape slider. hull means exact shape and bounding box will be a loose surround.
- Set the
Expansion distance
(I used 20 mils). This option expand the generated box with specified value.
- Click
Build for Signal Net
to generate the cookie cutter.
- Go to
Component/Pin Select
tab and select the components of interest. select pins you wish to add ports in Selected Pins
section.
- Select Ports tab and click on
AutoPlace
. Press OK
button and exit the Select Geometry
dialog.
- From
Export To ADS/EMPro
select Export > Selected To ADS
item.
- Select a path and click
Save
button.
Configuring ADS
Before being able to import ADFI file to ADS you need to do these simple steps to get ADS ADFI import tool enable
- In ADS main window, from menu bar select
Tools > App Manager
- In the opened dialog check
ADFI Import Tools
- Restart the ADS
Import to ADS
- Create a workspace or open an existed one.
- In the main window from menu bar select
File > Import > Design
- In the
File Type
section select ADFI File Format
from the list.
- Select your ADFI file and click on the
OK
button.
Extra Notes
1. Selecting the interested nets and creating ports in Allegro surly takes some time but the effort will payback in the simulation process (creating port in Allegro is much easier than in the ADS specially if you are dealing with a complex board)
2. After selection process saving the file WILL NOT save the selected nets. So if it take you too long to setup the board, don’t forget to save your work by using State > Save State
in Export To ADS/EMPro
menu bar
َََUseful Links
1. YouTube – ADS Data Link Basics (Part 1 of 3)
2. Keysight – EEsof EDA Blog
3. Dr. Muehlhaus -Momentum port: global ground or differential?
4. Virginia Tech – ADS Momentum Tutorial
Published on 2017-08-28 in
Software,
Windows
I use AutoHotkey in almost all my application but I notice some Qt applications (Like ADS) had some difficulty interpreting the AHK keys correctly. The problem turns out to be affiliated with UAC and Admin rights rather than the Qt library. To solve the issue simply add following lines to the top of your AHK scripts that you want to be applied on the specific app.
#SingleInstance Force
SetWorkingDir %A_ScriptDir%
if not A_IsAdmin
Run *RunAs "%A_ScriptFullPath%" ; Run Script as admin
This problem arises when you open a software instance with the admin rights while the AHK script doesn’t spawn with the same permission level. The above script simply run AHK with admin rights too so whether application is with or without admin right AHK script will always be able to set the key bindings.
Team Solid Squad
Published on 2017-07-20 in
Xilinx
State The Problem
This is a bug I found in many versions of Xilinx Vivado package and I actually now struggling with it in 2017.2 version. I don’t check out newer versions so it maybe already been solved, idk! Anyway, in my version on the Linux platform, if you open the SDK normally and then for whatever reason kill the machine or the program you cannot open the SDK again whatsoever. As I said I’m running Vivado on Arch Linux 2016.10 version so again this maybe not happen on Windows hosts.
Solution
There may be a lot of workaround for this, but this works for me more or less.
- Go to your Vivado project folder and enter your SDK sub folder.
- Trun on hidden visibility so you can see the dot files.
- Go to following path
<Vivado Project>/<proj name>.sdk/.metadata/.plugins/org.eclipse.core.resources
- Find a file with extention .snap and kill that bastard!!!
- Try to lunch SDK again and the problem should be gone.
Published on 2017-06-26 in
Electrical Engineering
Lately DDR3 is becoming more prevalent in new custom designs however I find that there isn’t much comprehensive document available for newcomers to the DDR franchise. Here I wrote down my own bootstrap on learning DDR3 jargons and way up to design and understand underline rationale behind the DDR3 length matching.
Why DDR
The first question you might ask is why to use DDR. All signals we send on wire or through air are occuping some bandwidth. On spectrum side, the signal bandwidth are so invaluable but what about on the PCBs. Is it important? Yes. The higher the bandwidth, the more delicate design is required and a higher loss would be observed on the signal path. This means that the higher frequencies portion would be attenuated more and to compensate that you need some sort of equlizer circuits like analog DFEs and … . But why bother to send higher bandwidth signals? In short, to acheive more data rate. So heres the thing. In these cases, DDR is used to maintain the bandwidth and at the same time doubles the data rate! How? You know…, by send and receive signal in both clock edges. and you know the rest.
DDR1, 2 and 3 Whats the difference
After that lets talk about the analogy between each ddr generation. In each leap in ddr generation the bus frequency would become higher and Vcc will be lower but except from these, the main improvement in each new version of DDR is incremental increases in prefetch bit size. Before I explain this more, you should know that apart from memory data rate, the internal clk frequency of DDR chip is not more than of 200MHz. So how a 200MHz memory could transfer data at rate of up to 102.4 Gb/s . The answer is by using as many as pins as possible, and using a serialising/deserialising technique.
DDR1 had prefetch size of 2 bit so the IO rate is doubled of internal rate by multiplexing 2 bit and send it in higher frequency on a single line. DDR2 has prefetch size of 4 bit and DDR3, 8 bit. Thats how DDR memories maintain their internal clk while acheiveing higher troughput in each new generation.
DDR Pins
Back to the main topic, lets introduce signaling of DDR chips. I assume a DDR3 chip here but you should able to generalize it to other DDR generation as well. At the top level, The DDR signals are divided into two categories, Data and nonData(CNTL/CLK/Address). The first thing is although it may not seem like it but these two categories have no relation with each other. Data category or DQ for short (Q used becuase of the same reason it used in Flip-Flop) have it’s own clock, DQS (Data strobe), while CNTL/CLK/Address are syncronized with other signal which is CLK. Therefore for routing (layout phase) on PCB each category should length match to ONLY it’s own members.
Behind The Scene
If you are not intrested in knowing how this is possible, please move on. So how Data send and recieved without syncronizing with addresses and control signals? The answer is they are synced at inside of the chip. DDR used a DLL (Delay Locked Loop) which add digital delay to signal to sync data and other signal from inside controller point of view. This pull out the pressure of matching all signal flight times and allow more degree of freedom and ease of use for DDR routing at the board level. The delay value will determined during Memory Training phase. This process is run after power up sequence and calibrate the delay of data group to the clk. The only requirment here is to have CLK be delayed longer than the longest DQS pair.
Byte Lane
Lukily data signals also breaks down into smaller group and each group has it’s own data strobe (CLK). With each byte lane have an independent clk, the contraint for length mathing diminish once more and only length matching inside a byte lane is required.
Data Group: DQ, DQS
Address/CMD Group: Address, RAS ,CAS ,MWE
Control Group: CS, CKE, ODT
Clock Group: CLK
Final Note
Following checklist should be served as a good epilogue for this post:
- Transmission Line Impedance should be 40Ohm with 10 percent tolerance
- CLK trace should be longer than the longest DQS path
- DQ signal are allowed to swap inside of a byte lane
- Cross talk is an important issues in DDR3 SI. micron have a good constraint about how much signals can be tightening together.
- For ZYNQ-7000 10ps is the length mathing margin. It translate to 10mils on a FR4 substrate.
Useful Links
StackExchange – Rams and DQ lines
GitHub – Understanding DDR Memory Training
Xilinx – DQS to CK maximum on Zynq PS DDR Controller
Is it good practice to length match all traces of DDR3
Published on 2017-05-27 in
Linux
One of the great feature of XInput is “Mouse Wheel Emulation” that I graceful with it for more than 5 years. Lately I notice it relieve my hand If I could trig wheel emulation by a key on keyboard instead of a mouse button.
Unfortunately up to this time Evdev not support that and pushing a mouse button through a synthetic way (like using bash script or liunx API) won’t trick EvDev. The reason behind this is that Evdev Wheel Emulation is a device specific driver. you won’t be able to enable it on all devices so it only executed if a button is pressed only on the specific device that you enable emulation on . Moreover after the triggering, wheel emulation only apply to movement of this specific devices with trigger. The figure below show two scenario that lead to unsuccessful wheel emulation.
In a nutshell if you press mouse button source from a bash script emulation not work because EvDev driver won’t get it at all thus the button press have to come from a event-based device and not a complete virtual software. Additionally the movement and button press should come from same device. So as shown in the image, movement on Mouse #1 won’t do the emulation triggered from Mouse #2. To recap:
- The button press should come from an event-based device
- Trigger and movement should be on same device
Solution: Uinput-Mapper
Uinput is a kernel module to create event-based device. Uinput-Mapper is a wrapper around uinput in python that can create duplicate from a physical device and then manipulate it. Unfortunately python and Uinput-Mapper are slow and that can cause unexpected lag on mouse movement so the idea in here is to only use Uinput-Mapper under necessary cicumstances.
Uinput-Mapper can be cloned from this github repositories. If you get a glimpse of uinput-mapper, you notice two files input-read
and input-create
. input-read is a python script that read all event from a event-based device and spit all events out in form of pickle to stdout. For those who like me that don’t know what pickle is, pickle is a saving format. It can save and restore any type of variable so with power of pickle you can save a complex class and restor all variables and function in the state that it had been saved before.
Now what is input-create? input-create is twin of input-read that first create a event-base device and then get all event from stdin in form of pickle and then execut the events on a virtual device that has been just created by the script. To summerize input-read capture all events from an actual device and convert it to pickle, and then input create duplicate device and execute captured events coming from input-read.
So you had to pipeline all output of input read to input-create with something like command shown below
$ ./input-read -D /dev/input/event3 | ./input-create
The -D
option in above command imply that input-read
output is in format of pickle(not in a human readable format).
Keycode Based Shortcut Trigger
Now the time hase come to manipulate uinput-mapper to our requiment. I think posting all codes in here will clutter the post structure so I explain basic of modification applied on uinput-mapper and leave all codes to my github Bijoux repository.
First we need a script to trigger on pressing a key on keyboard. For sake of simplicity and because of my extra experience with bash I use bash over python to do the key detection and then used stdio to pass it to input-read. The big picture here is first using input-mapper we create a duplicate of our physical mouse. How? by running exact command mentioned above. Then we disable the physical mouse in XInput by running
$ xinput disable $MOUSE_ID
Now instead of data passing directly to EvDev, it pipelined through synthetic event-base device and then pass to EvDev. Here the trick is to write a script (we call it shortcut from now on) to detect a shortcut and then when a shortcut is detected we inject a synthetic event into virtual mouse that we have been created previously. Now from EvDev perspective, this won’t be any different from the event Physical Mouse #1 generate so it trigger the emulation wheel and moving in x/y direction actually scroll the screen on the active window. The figure below demostrate the forgoing concept.
shortcut script detect a key press -> send a notification to input-read -> input-read load a previously recorded button press -> send recorded event to uinput-create -> uinput-create execute synthethic event as the same as other event come from mouse #1 -> …
Performance Issue
As remark previously, python scripts are slow intrinsically passing all mouse events through it cannot be accepted from performance point of view. Furthuremore in my brief test script runtime speed create not dramatic but noticable lag on mouse movement. To solve this issue bridge solution described above should only applied if and only if the wheel emulation should excute on that time. To do that following vivid shortcut (script) clears how this can be done.
The script is nothing more than a program than switch between physical mouse and virtual mouse on the fly. This is accomplished by using enable/disable function of XInput
#!/bin/bash
MOUSE_ID=($(xinput list | grep -m 1 MOUSE_MODEL | awk -F "=" '{print $2}' | awk -F " " '{print $1}'))
VIRTUAL_ID=14
while read -r line
do
#echo $line
if [ "$line" == "key press 108" ];then
echo 1 #inform input-read
xinput disable $MOUSE_ID
xinput enable $VIRTUAL_ID
while read -r line
do
if [ "$line" == "key release 108" ];then
echo 0 #inform input-read
xinput enable $MOUSE_ID
xinput disable $VIRTUAL_ID
break
else
break
fi
done < <(xinput test 12)
fi
done < <(xinput test 12)