wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 06:32:13 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 09:43:09PM -0600, Elizabeth Figura wrote: > > > Why do you need a fixed minor number? Can't your userspace handle > > > dynamic numbers? What systems require a static value? > > > > I believe I added this because it's necessary for MODULE_ALIAS (and, more > > broadly, because I was following the example of vaguely comparable devices > > like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS > > (or even remove the ability to compile ntsync as a module entirely). > > Do you really need MODULE_ALIAS()? Having it for char devices to be > auto-loaded is not generally considered a good idea anymore as systems > should have the module loaded before userspace goes and asks for it. > > It also reduces suprises when any random userspace program can cause > kernel modules to be loaded for no real reason. I think there's no reason we can't make loading the system's problem. I'll remove it in v2.

1 0

Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:38:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > ntsync uses a misc device as the simplest and least intrusive uAPI interface. > > > > Each file description on the device represents an isolated NT instance, intended > > to correspond to a single NT virtual machine. > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > I'm looking at the ioctl interface to ensure it's well-formed. > > Your patches look ok from that perspective, but there are a > few minor things I would check for consistency here: > > > + > > +static const struct file_operations ntsync_fops = { > > + .owner = THIS_MODULE, > > + .open = ntsync_char_open, > > + .release = ntsync_char_release, > > + .unlocked_ioctl = ntsync_char_ioctl, > > + .compat_ioctl = ntsync_char_ioctl, > > + .llseek = no_llseek, > > +}; > > The .compat_ioctl pointer should point to compat_ptr_ioctl() > since the actual ioctl commands all take pointers instead > of interpreting the argument as a number. > > On x86 and arm64 this won't make a difference as compat_ptr() > is a nop. Thanks; will fix.

1 0

Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:54:02 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:21PM -0600, Elizabeth Figura wrote: > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > --- > > Note, we can't take patches without any changelog text, and you don't > want us to :) > > > Documentation/admin-guide/devices.txt | 3 ++- > > Documentation/userspace-api/ioctl/ioctl-number.rst | 2 ++ > > drivers/misc/ntsync.c | 3 ++- > > include/linux/miscdevice.h | 1 + > > 4 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/admin-guide/devices.txt > > b/Documentation/admin-guide/devices.txt index 94c98be1329a..041404397ee5 > > 100644 > > --- a/Documentation/admin-guide/devices.txt > > +++ b/Documentation/admin-guide/devices.txt > > @@ -376,8 +376,9 @@ > > > > 240 = /dev/userio Serio driver testing device > > 241 = /dev/vhost-vsock Host kernel driver for virtio vsock > > 242 = /dev/rfkill Turning off radio transmissions (rfkill) > > > > + 243 = /dev/ntsync NT synchronization primitive device > > > > - 243-254 Reserved for local use > > + 244-254 Reserved for local use > > Why do you need a fixed minor number? Can't your userspace handle > dynamic numbers? What systems require a static value? I believe I added this because it's necessary for MODULE_ALIAS (and, more broadly, because I was following the example of vaguely comparable devices like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS (or even remove the ability to compile ntsync as a module entirely). It's a bit difficult to figure out what's the preferred way to organize things like this (there not being a lot of precedent for this kind of driver) so I'd appreciate any direction. --Zeb

1 0

Re: [RFC PATCH 3/9] ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 19:14:17 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:22PM -0600, Elizabeth Figura wrote: > > +static int ntsync_create_sem(struct ntsync_device *dev, void __user > > *argp) > > +{ > > + struct ntsync_sem_args __user *user_args = argp; > > + struct ntsync_sem_args args; > > + struct ntsync_obj *sem; > > + __u32 id; > > + int ret; > > + > > + if (copy_from_user(&args, argp, sizeof(args))) > > + return -EFAULT; > > + > > + if (args.count > args.max) > > + return -EINVAL; > > No bounds checking on count or max? > > What's the relationship between count and max? Indeed, no bounds checking. The counter is just the semaphore's internal value and has no meaning other than that. It's basically like an EFD_SEMAPHORE, except that the maximum is configurable rather than always being 2**64-2. > Some sort of real > documentation is needed here, the changelog needs to explain this. Or > somewhere, but as-is, this patch series is pretty unreviewable as I > can't figure out how to review it because I don't know what it wants to > do. There is some comprehensive documentation in the series, but for ease of review I will try to write a basic description of the API in each relevant patch in v2.

1 0

Re: [RFC PATCH 0/9] NT synchronization primitive driver
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:59:35 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:19PM -0600, Elizabeth Figura wrote: > > == Patches == > > > > This is the first part of a 32-patch series. The series comprises 17 patches > > which contain the actual implementation, 13 which provide self-tests, 1 to > > update the MAINTAINERS file, and 1 to add API documentation. > > 32 patches? I only see 9 here, why not submit them all? Because Documentation/process/submitting-patches.rst makes a point of asking people not to submit large patch series (and it matches the expectation of other projects I've worked with—that patches would be submitted and reviewed a few at a time). I suppose I've misunderstood that advice, though. I'll resend with the entire series. Sorry for the noise.

1 0

9.0 release notes, please review
by Alexandre Julliard 18 Jan '24

18 Jan '24

Folks, We've once again made very good progress on the regressions during this code freeze period, thanks to everybody for your help! It's now time for the final release. I've attached the tentative release notes, written with help from Jacek, Rémi and Zeb, and for the first time in Markdown format <g>. Please review these and let me know if anything is wrong, missing, or unclear. -- Alexandre Julliard julliard(a)winehq.org

8 17

Force feedback auto center implementation?
by Tyson Whitehead 13 Jan '24

13 Jan '24

Would like to get disabling force feedback auto-centering working so that trimming will work properly with force feedback devices in flight simulators. Currently the call to disable it is a stub static HRESULT dinput_device_set_property( IDirectInputDevice8W *iface, const GUID *guid, const DIPROPHEADER *header ) { ... case (DWORD_PTR)DIPROP_AUTOCENTER: { const DIPROPDWORD *value = (const DIPROPDWORD *)header; if (!(impl->caps.dwFlags & DIDC_FORCEFEEDBACK)) return DIERR_UNSUPPORTED; if ( header->dwHow != DIPH_DEVICE) return DIERR_INVALIDPARAM; impl->vtbl->set_property( iface, FIXME( "DIPROP_AUTOCENTER stub!\n" ); impl->autocenter = value->dwData; return DI_OK; } ... } After having looked through the wine, SDL, and kernel code and read up on the force feedback HID physical interface device (PID) usage table reports, I am guessing this was left as a stub because it doesn't fit in with the current design of dipnut communicating with the backend via HID reports. The issue being that auto centering, unlike everything else, isn't part of the PID specification, so there isn't a predefined report that can be used for this (see table 0x0f) https://www.usb.org/document-library/hid-usage-tables-14 Although I am no wine or Windows code expert, I am guess this leaves the following options - leave it disabled in the backend and emulate it via a frontend spring effect - abuse an existing HID report to communicate it - add a WINE specific HID report to communicate it - add a WINE specific IOCTL to communicate it For the first option, I mean have the winebus backends disable it via the kernel or an SDL call and then have the dinput layer enable simulate it by adding a default spring effect. This then lets the dinput frontend disable it again by removing or disabling its spring effect. For the second one I mean something like reserve an effect ID for specifying auto centering. Both of these are inspired by the fact that from the kernel code, it seems auto centering for HID devices is an undocumented use of the first effect ID for a spring effect https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… Would be interesting in knowing what sort of implementation people think would be best and acceptable for inclusion into wine? Thanks! Tyson

2 8

Wine staging 9.0-rc5 release
by Alistair Leslie-Hughes 13 Jan '24

13 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc5 (500 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

vkd3d request
by Alistair Leslie-Hughes 09 Jan '24

09 Jan '24

Hi All, Now that vkd3d 1.10 is out, I have a request for developers. Would it be possible to include a file of all games/applications that have fixes when they are committed. It's too hard to track unless you really doing serious work with it. The whole concept of including the latest vk3d3d in staging was to help with testing but if people don't know what to test, they wont. This would also, give a nice section in the ANNOUNCE as to what now works. :) Best Regards Alistair

3 4

[PATCH] po: Update Asturian translation
by Enol P. 08 Jan '24

08 Jan '24

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel