Move button-event reporting behind pointer-position update.
This is just a quickfix to restore correct pointer emulation with
dde_linux usb_drv. It does not change usb_hid_drv because the approach
is a questionable workaround of the current input event handling, which
reports events promptly on occurrence of inputs events and ignores
synchronization events completely. The original contrib code reported
the button press before absolute x and y positioning followed by a sync
event.
Issue #3019
The 'connected_scan_interval' config attribute specifies the scan
interval in seconds. The commit also removes the deprecated ram_fs
component from the test run script.
The 11n mode can forcefully be disabled by setting the 'disable_11n'
attribute to 'true'. This is workaround for certain 6200 ABG cards
that apparently do not support this mode.
Fixes#2124.
The modular lx_kit seperates the required back end functionality of the
Linux emulation environment from the front end. Thereby each driver can
reuse specific parts or supply more suitable implementations by itself.
It is used to reduce the amount of redundant code in each driver.
The lx_kit is split into several layers whose structure is as follows:
The first layer in _repos/dde_linux/src/include/lx_emul_ contains those
header files that provide the structural definitions and function
declarations of the Linux API, e.g. _errno.h_ provides all error code
values. The second layer in _repos/dde_linux/src/include/lx_emul/impl_
contains the implementation of selected functions, e.g. _slab.h_
provides the implementation of 'kmalloc()'. The lx_kit back end API is
the third layer and provides the _Lx::Malloc_ interface
(_repos/dde_linux/src/include/lx_kit/malloc.h_) which is used to
implement 'kmalloc()'. There are several generic implementations of the
lx_kit interfaces that can be used by a driver.
A driver typically includes a 'lx_emul/impl/xyz.h' header once
directly in its lx_emul compilation unit. The lx_kit interface files
are only included in those compilation units that use or implement the
interface. If a driver wants to use a generic implementation it must
add the source file to its source file list. The generic
implementations are located in _repos/dde_linux/src/lx_kit/_.
The modular lx_kit still depends on the private _lx_emul.h_ header file
that is tailored to each driver. Since the lx_kit already contains much
of the declarations and definitions that were originally placed in
these private header files, those files can now ommit a large amount
of code.
Fixes#1974.
- Use 'label' attribute to identify device instead of
bus/dev and vendor_id/product_id
- Implement release_interface RPC
- Report 'label' as well as 'bus' and 'dev'
- Add policy handling to raw driver (includes reconfiguration
at runtime)
- Use own memory backing store for large DMA allocations
Issue #1863.
The report lists all connected devices and gets updated when devices are
added or removed.
Example report:
<devices>
<device vendor_id="0x17ef" product_id="0x4816"/>
<device vendor_id="0x0a5c" product_id="0x217f"/>
<device vendor_id="0x8087" product_id="0x0020"/>
<device vendor_id="0x8087" product_id="0x0020"/>
<device vendor_id="0x1d6b" product_id="0x0002"/>
<device vendor_id="0x1d6b" product_id="0x0002"/>
</devices>
There is no distinction yet for multiple devices of the same type.
The report is named "devices" and an example policy for 'report_rom' would
look like:
<policy label="vbox -> usb_devices" report="usb_drv -> devices"/>
The report only gets generated if enabled in the 'usb_drv' configuration:
<config>
<raw>
<report devices="yes"/>
</raw>
</config>
Fixes#1506
The wifi_drv now provides two reports. The first one contains all
accesspoints that were found while scanning the supported frequencies.
The second one reports the state of the driver, i.e., if it is
conntected to an accesspoint or not. In addition to that, the driver
now gets its configuration via a ROM session.
More detailed information are available in 'repos/dde_linux/README'.
Issue #1415.
This patch changes the top-level directory layout as a preparatory
step for improving the tools for managing 3rd-party source codes.
The rationale is described in the issue referenced below.
Issue #1082
