Gerald Pfeifer <gerald(a)pfeifer.com> writes:
> So, I admit I don't really know this code, but looking at it (triggered
> by a warning issued by GCC development versions), I noticed that this
> variable passed by reference is not initialized here.
It's initialized when we return a type, and it doesn't need to be
initialized on NULL return. The code is correct, but you could probably
set the variable to NULL in the caller to silence the warning.
--
Alexandre Julliard
julliard(a)winehq.org
Looking at
RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector )
{
RPC_STATUS status;
ULONG c;
TRACE("(%p)\n", BindingVector);
for (c=0; c<(*BindingVector)->Count; c++) {
status = RpcBindingFree(&(*BindingVector)->BindingH[c]);
}
HeapFree(GetProcessHeap(), 0, *BindingVector);
*BindingVector = NULL;
return RPC_S_OK;
}
we currently always ignore the outcome of RpcBindingFree and return
RPC_S_OK.
However, there is one case where RpcBindingFree returns something
different (which is if *Binding is null when RPC_S_INVALID_BINDING
is returned).
What is the proper way of handling this? Just keeping the code as
is and removing the unused status variable? Breaking the loop once
RpcBindingFree returns something different from RPC_S_OK? Continuing
and returning the first / the last status different from RPC_S_OK?
Gerald
Here are some things I've learned about PCI-passthrough recently, which
would be one way (probably the best) to add "real hardware" to the
TestBot.
I don't want to give anyone false hopes though: this just went from
"this is a mysterious thing I need to learn about" to "I think I know
how to do it but have not tried it yet".
So graphics card PCI-passthrough is now relatively well documented on
the Internet and seems to have seen some use-cases that would indicate
it may even be reasonably usable.
* There are two machines intended to run real GPU tests for Wine:
cw1-hd6800 and cw2-gtx560. For now they are only used to run WineTest
daily on Windows 8.1, Windows 10 1507, 1709, 1809 and Linux. That's
quite a bunch but it would be much better if they were integrated with
the TestBot as that would allow developers to submit their own tests.
So I had a look at what it would imply to convert them to VM hosts
using QEmu + PCI-passthrough.
* First one needs a processor with hardware virtualisation support. For
Intel that's VT-d. Both machines have an Intel Core 2600 which
supports VT-d. Good.
* Second the motherboard too needs to support VT-d. Both machines have
an ASRock P67 Extreme4 motherboard. Unfortunately UEFI says
"unsupported" next to the "VT-d" setting for the motherboard :-( It
looks like there was some confusion as to whether the P67 chipset
supported VT-d initially. From what I gathered it's only Q67 that does
but this caused some manufacturers, among which ASRock, to initially
claim support and later retract it.
* Then one needs to add the intel_iommu=on option to the kernel command
line (resp. amd_iommu). This is should make all the PCI devices appear
in /sys/kernel/iommu_groups. But that folder remains empty which
confirms that full VT-d support is missing.
* Another important aspect is to have a graphics card which is
hot-restartable. In some cases when a VM's graphics card is crashed
the only way to reset it is to reboot the host. The TestBot is likely
to crash the graphics card, particularly if we do a hard-power off on
the VMs like we currently do, and it would relaly be annoying to have
to reboot the host everytime the graphics card goes belly up.
I don't know if the AMD HD6800 and Nvidia GTX560 are suitable but it's
quite possible they are not. All I know for now is that we should
avoid AMD's R9 line of graphics cards. I still need to find a couple
of suitable reasonably lower power graphics cards: one AMD and one
Nvidia.
* Then one needs to prevent the host from using the graphics card.
Usually that's done by having the host use the processor's IGP and
dedicating the discrete GPU to the VMs. Unfortunately the 2600's IGP
cannot be active when there's a discrete card so that route is denied
to us. Fortunately there's quite a bit of documentation on how to shut
down not just X but also the Linux virtual consoles to free the GPU
and hand it over to the VMs after boot.
Doing so means losing KVM access to the host which is a bit annoying
in case something goes wrong. So ideally we'd make sure this does not
happen in grub's "safe mode" boot option.
* Although I have not done any test yet I'm reasonably certain that
PCI-passthrough rules out live snapshots: QEmu would have no way to
restore the graphics card's internal state.
- For Windows VMs that's not an issue: if we provide a power off
snapshot the TestBot already knows how to power on the VM and wait
for it to boot (as long as the boot is shorter than the connection
timeout but it works out usually).
- For Linux VM's that's more of an issue: the TestBot will power on
the VM as usual. The problem is when it updates Wine: after
recompiling everything it deletes the old snapshot and creates a new
one from the current state of the VM, which means a live snapshot.
So the TestBot will need to be modified so it knows when and how to
power off the VM and take a powered off snapshot.
* Since the VM has full control of the graphics card QEmu has no access
to the content of the screen. That's not an issue for the normal
TestBot operation, just for the initial VM setup. Fortunately the
graphics card is connected to a KVM so the screen can be accessed
through that means. It does mean assigning the mouse and keyboard to
the VM too. Should that prove impractical there are a bunch of other
options too: VNC, LookingGlass, Synergy, etc. But the less needs to be
installed in the VMs the better.
* Also the TestBot uses QEmu to take the screenshots. But QEmu does not
have access to the content of the screen. The fix is to use a tool to
take the screenshots from within the VM and use TestAgent to retrieve
them. On Linux there are standard tools we can use. On Windows there's
code floating around we can use.
So the next steps would be:
* Maybe test on my box using the builtin IGP.
But that likely won't be very conclusive beyond confirming the
snapshot issues, screen access, etc.
* Find a suitable AMD or Nvidia graphics card and test that on my box.
That would allow me to fully test integration with the TestBot, check
for stability issues, etc.
* Then see what can be done with the existing cw1 and cw2 boxes.
--
Francois Gouget <fgouget(a)codeweavers.com>
Hi,
What is the status of development regarding Wine Gecko? The last general release was
June 2016. As the maintainer in Fedora I have a few concerns that I would like to
address.
1. The build scripts require Python 2. Fedora is dropping Python 2 in Fedora 31/32.
31 is only a few months away from GA.
2. I have been unable to build from source with the latest MinGW toolset since
November 2016. I've last reported this directly to Jacek in 2018, but I have never
heard from him.
3. If no support arrives, I don't have the time to patch wine-gecko. It will be
dropped from Fedora and users will be downloading the binaries from winehq.org. This
provides a reduced user experience and I would like to prevent it.
Thanks,
Michael
Hello,
Again this year I am helping coordinate the talks and presentations! I hope that people find it helpful and useful! Last work worked out well enough that I am sticking to the same rough format. I think it worked for most other people as well!
If you would like to give a presentation! Please e-mail wineconf(a)winehq.org or me directly! I will keep the Wiki updated with presentations and scheduling as we get it worked out.
When you propose your talk if you have a preference toward a time slot and Saturday or Sunday please express that.
General Guidelines:
* Please provide an estimate of how long your talk will be. We are shooting for approximate 40 minute slots with between 15-20 minutes of talk and with likely an equal amount of question and discussion time afterward. Generally shorter talks are not an issue, however longer talks will need to be discussed and will be considered based on the rest of the schedule.
* Topics should obviously be of interest to the other attendees, i.e., the broader Wine community, but note that that doesn't imply the talk has to be about Wine itself
* If you have a preferred time and date for your talk please indicate that to me when you submit your talk. We will try to make it work as best we can.
Here are the rough proposed slots, They will be changed and modified as required by the addenda as it gets fleshed out. Understand that even with this shift toward a scheduled day we will not disrupt productive conversation to fit to the schedule. The schedule will warp and flow as required to facilitate the talk, not force the talks to conform to it. This does mean if you are planing to try to attend a given talk you will likely want to arrive a bit early and understand if when you arrive the schedule is either behind or ahead of plan.
Daily Slots:
09:00 - 09:40 slot 1
09:45 - 10:25 slot 2
10:30 - 11:00 break
11:00 - 11:40 slot 3
12:00 - 13:00 lunch break
13:00 - 13:40 slot 4
13:45 - 14:25 slot 5
14:30 - 15:00 break
15:00 - 15:40 slot 6
15:45 - 16:25 slot 7
16:25 - 17:00 Overflow time / small group discussion / short presentations
We will track proposed presentations on the WineConf Wiki: https://wiki.winehq.org/WineConf2019
Likely we will have open time at the conference which we will propose presentations and fill at the time. We have never had a problem finding things we all want to talk about.
thanks!
-aric
Does anyone know how to automate adding new languages to Windows 10?
I have a script that can automate switching the locale settings of a
TestBot VM. It can even automatically create the live snapshots that the
TestBot needs [1].
But before it can do its magic it needs the requested locale to be
installed. Now I'd like it to be able to automate installing the
required locale too, particularly on Windows 10. When I did it manually
I noticed that Windows 10 asked me a bunch of customization questions on
reboot. Those would obviously have to be skipped too.
Note that in this scenarion Windows is already installed and running. So
the 'Windows unattended install' tools may or may not be useful.
[1] https://source.winehq.org/git/tools.git/blob/HEAD:/testbot/scripts/SetWinLo…
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Sufficently advanced incompetence is indistinguishable from malice.
Resending these here after iterating a bit in background for further
discussion.
I squashed a fix from Zhiyi Zhang <zzhang(a)codeweavers.com> in PATCH 3/6.
Rémi Bernon (6):
winex11.drv: Do not react to keyboard grab focus events
winex11.drv: Only grab or warp the cursor when keyboard isn't grabbed
winex11.drv: Retry last ClipCursor when grab is released
winex11.drv: Do not set clipping_cursor when clip window map state
changes
winex11.drv: Explicitly call XUngrabPointer when clipping is released
winex11.drv: Only call XWarpPointer if we can get exclusive pointer
grab
dlls/winex11.drv/event.c | 47 +++++++++++++++++++++++++++++++++---
dlls/winex11.drv/mouse.c | 50 +++++++++++++++++++++++++++++++++++++++
dlls/winex11.drv/x11drv.h | 2 ++
3 files changed, 96 insertions(+), 3 deletions(-)
--
2.23.0.rc1