This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
~~`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2)~~
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v34: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs.
dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path.
dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ.
dlls/winebth.sys: Add a basic unixlib stub using DBus.
dlls/winebth.sys: Add base winebth.sys driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
Overriding the SDL_VIDEODRIVER variable (for Wayland support as an example)
on the Linux side can lead to some games under Wine failing to load (so treat
that variable as special).
--
v6: ntdll: Add SDL audio driver variables to the special variables list.
ntdll: Add SDL video driver variables to the special variables list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5231
This serie is a first attempt to provide a solution to bug 57308 [1].
Basically, Arch distro is looking for Wine support in distributing
debug information for Wine PE modules separated from image.
A quick overview of distro (Debian, Fedora, Arch) situation i
(I may have missed a couple of items), but:
- no distro ship separate debug information for PE modules
(they do it for ELF ones though)
- at best, they ship unstripped PE modules.
IMO, we need to help them pave the way to what should be the best
expected situation (in Wine and wrt distros) to support separate
debug information for PE images.
First, I believe we need to use a (solid) key to bind the
stripped image and the file holding the debug information.
In ELF format, this is typically done by inserting a
.note.gnu.build-id section (in both stripped image and
debug information file) which contains the key.
This key is used to either search in fixed location
(eg /usr/lib/.debug), or as key to download the debug
information from a remote server (debuginfod).
The key is generally made of a hash of (some sections of)
the image file.
This allows (esp. in the case of downloading the debug
information from a debugger) to discriminate between
several versions of the same module.
I think we should target this kind of solution instead of
storing the debug information alongside the module
(usually done as ntdll.dll.debug).
This wouldn't let debuggers download the expected debug info
upon request.
Fortunately, gcc and clang provide a build-id option
(when generating PE images) which stores this key in
the PE image.
What this serie does:
- fixes & improves dbghelp in the support of the
build-id information from gcc/mingw & clang,
- improves Wine's configure script so that
clang can be used to generate dwarf debug information
and build-id information in PE builds,
- adds a couple of additional search locations for
debug information files,
It takes the following assumptions for the storage:
- debug information files for PE images are stored
in same hierarchy as debug information files for
ELF images (eg /usr/lib/.debug)
- naming of such files is done as ELF, ie by using
the hex string generated from the binary blob
of the key. This is *NOT* the usual way how the
GUID will be printed (because the first 3 integers
of the GUID are stored in little-endian format).
(Note: I had to make a choice here. I don't have
strong arguments one way or the other, but we
need to agree on the convention here).
What distro should do to support separate debug info:
- configure Wine with --enable-build-id
- adapt at least the packaging tool to extract the
key out of unstripped image [2],
- if binutils isn't compiled with PE support (this
is apparently the Arch case), adapt the scripts to
use x86_64-objcopy instead of objcopy (and friends).
I marked this MR as draft for now, as:
- I still need to polish some items (like the default
location for looking up debug information files),
- wait for feedback on this proposal (it does make
a couple of assumptions that need sharing IMO),
Further steps:
- the steps above are mainly targetted to have a solution
for packaged download of debug information files,
- this should be integrated in debuginfod (server side:
ingestion of PE files and client side: ensure gdb, lldb
are compatible; implement debuginfod in winedbg).
Feed back welcomed!
[1]: https://bugs.winehq.org/show_bug.cgi?id=57308
[2]:
The least invasive readelf replacement (assuming binutils is compiled with PE support).
(otherwise, use x86_64-objdump)
BUILDID=`objdump -p "$INPUT" | sed -n "/RSDS signature / {s/.*signature //; s/ age.*//p; q;}"`
BUILDID=${BUILDID:6:2}${BUILDID:4:2}${BUILDID:2:2}${BUILDID:0:2}${BUILDID:10:2}${BUILDID:8:2}${BUILDID:14:2}${BUILDID:12:2}${BUILDID:16}
Additional note: gcc/mingw puts the desired debug entry inside a dedicated
section (.buildid), while clangs keeps it in .rdata (as msvc does).
So, this invalidates any attempt to get information from the .buildid section
(as stated in bug report).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6715