wine-devel January 2024

wine-devel@winehq.org

20 participants
28 discussions

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 13:52:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 19:02, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 01:56:52 CST Arnd Bergmann wrote: > >> On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > >> > >> > + if (args->timeout) { > >> > + struct timespec64 to; > >> > + > >> > + if (get_timespec64(&to, u64_to_user_ptr(args->timeout))) > >> > +… [View More]

1 0

Re: [RFC PATCH 8/9] ntsync: Introduce NTSYNC_IOC_PUT_MUTEX.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:42:19 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > @@ -738,6 +803,8 @@ static long ntsync_char_ioctl(struct file *file, > > diff --git a/include/uapi/linux/ntsync.h b/include/uapi/linux/ntsync.h > > index 26d1b3d4847f..2e44e7e77776 100644 > > --- a/include/uapi/linux/ntsync.h > > +++ b/include/uapi/linux/ntsync.h > > @@ -46,5 +46,7 @@ struct ntsync_wait_args { > > … [View More]

1 0

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:56:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > > + if (args->timeout) { > > + struct timespec64 to; > > + > > + if (get_timespec64(&to, u64_to_user_ptr(args->timeout))) > > + return -EFAULT; > > + if (!timespec64_valid(&to)) > > + return -EINVAL; > > + > > + timeout = timespec64_to_ns(&to); > > + } > > Have you … [View More]

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 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-… [View More]

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 … [View More]

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/… [View More]

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)… [View More]

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 … [View More]

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-&… [View More]gt;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 [View Less]

2 8

2025

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 January 2024