xf86-video-intel is broken and with MRs disables we can't fix it

xf86-video-intel is broken and with MRs disables we can't fix it

[Povilas Kanapickas]

Hi,

xf86-video-intel driver is currently cannot be compiled with released
versions of X server. Simple reproduction steps: create Debian Bookworm
container, download module sources and all required dependencies and try
to build.

Debian Bookworm is pretty much the least exciting configuration
possible. And the fact that xf86-video-intel cannot be compiled there is
not good.

For almost any other driver this is not a problem, because it is
possible to create a merge request on gitlab.freedesktop.org. Eventually
simple maintenance and build-related merge requests are merged. However
in the case of Intel driver, merge requests are disabled and the
recommended way to submit patches is via intel-gfx@lists.freedesktop.org
mailing list. Unfortunately, patches submitted so far are ignored there.

Given that the last commit to xf86-video-intel was 22 months ago, I
suspect there's little interest from Intel to spend time maintaining the
project.

What do you think about opening up merge requests on the repository so
that at least the driver can be brought back to compilable state? Does
anyone have other ideas how the current situation could be resolved?

Regards,
Povilas

Re: xf86-video-intel is broken and with MRs disables we can't fix it

[Ville Syrjälä]

On Fri, Feb 07, 2025 at 08:57:34PM +0200, Povilas Kanapickas wrote:
> Hi,
> 
> xf86-video-intel driver is currently cannot be compiled with released
> versions of X server. Simple reproduction steps: create Debian Bookworm
> container, download module sources and all required dependencies and try
> to build.

Builds fine on my Gentoo boxes here. What are the actual issues
you are seeing?

> 
> Debian Bookworm is pretty much the least exciting configuration
> possible. And the fact that xf86-video-intel cannot be compiled there is
> not good.
> 
> For almost any other driver this is not a problem, because it is
> possible to create a merge request on gitlab.freedesktop.org. Eventually
> simple maintenance and build-related merge requests are merged. However
> in the case of Intel driver, merge requests are disabled and the
> recommended way to submit patches is via intel-gfx@lists.freedesktop.org
> mailing list. Unfortunately, patches submitted so far are ignored there.

I've not seen any patches on the list. Care to point them out?

> 
> Given that the last commit to xf86-video-intel was 22 months ago, I
> suspect there's little interest from Intel to spend time maintaining the
> project.

You must be looking at some stale repo. My last commit was 
commit ce811e78882d9f31636351dfe65351f4ded52c74
Author:     Ville Syrjälä <ville.syrjala@linux.intel.com>
AuthorDate: Sat Mar 18 15:45:44 2023 +0200
Commit:     Ville Syrjälä <ville.syrjala@linux.intel.com>
CommitDate: Tue May 7 00:32:24 2024 +0300

> 
> What do you think about opening up merge requests on the repository so
> that at least the driver can be brought back to compilable state? Does
> anyone have other ideas how the current situation could be resolved?

I wouldn't want to deal with mrs for any high volume stuff, but
since this only gets the occasional fix I guess it could work.

-- 
Ville Syrjälä
Intel

Re: xf86-video-intel is broken and with MRs disables we can't fix it

[Povilas Kanapickas]

Hi Ville,

Thanks for quick response.

Turns out due to multiple factors leading to my confusion most parts of
the email are plainly wrong. Apologies for going to public mailing list
without more research and discussion.

On 2025-02-07 23:25, Ville Syrjälä wrote:
> On Fri, Feb 07, 2025 at 08:57:34PM +0200, Povilas Kanapickas wrote:
>> Hi,
>>
>> xf86-video-intel driver is currently cannot be compiled with released
>> versions of X server. Simple reproduction steps: create Debian Bookworm
>> container, download module sources and all required dependencies and try
>> to build.
> 
> Builds fine on my Gentoo boxes here. What are the actual issues
> you are seeing?

Linking failure on meson due to missing XvGetPortAttribute, and failure
to even start building on autotools. I think since you're responding I
will simply submit patches your preferred way.

>>
>> Debian Bookworm is pretty much the least exciting configuration
>> possible. And the fact that xf86-video-intel cannot be compiled there is
>> not good.
>>
>> For almost any other driver this is not a problem, because it is
>> possible to create a merge request on gitlab.freedesktop.org. Eventually
>> simple maintenance and build-related merge requests are merged. However
>> in the case of Intel driver, merge requests are disabled and the
>> recommended way to submit patches is via intel-gfx@lists.freedesktop.org
>> mailing list. Unfortunately, patches submitted so far are ignored there.
> 
> I've not seen any patches on the list. Care to point them out?

The patches are on February 2024, but I must admit I didn't double check
on the list and there in fact are your review responses to these. The
submitter simply didn't follow through.

>>
>> Given that the last commit to xf86-video-intel was 22 months ago, I
>> suspect there's little interest from Intel to spend time maintaining the
>> project.
> 
> You must be looking at some stale repo. My last commit was 
> commit ce811e78882d9f31636351dfe65351f4ded52c74
> Author:     Ville Syrjälä <ville.syrjala@linux.intel.com>
> AuthorDate: Sat Mar 18 15:45:44 2023 +0200
> Commit:     Ville Syrjälä <ville.syrjala@linux.intel.com>
> CommitDate: Tue May 7 00:32:24 2024 +0300

Sorry, I looked into author date only :-(

>>
>> What do you think about opening up merge requests on the repository so
>> that at least the driver can be brought back to compilable state? Does
>> anyone have other ideas how the current situation could be resolved?
> 
> I wouldn't want to deal with mrs for any high volume stuff, but
> since this only gets the occasional fix I guess it could work.

Thanks. I think that it doesn't make sense to change anything since the
premise of my email was wrong.

Sorry for wasting time.

Regards,
Povilas

Re: xf86-video-intel is broken and with MRs disables we can't fix it

[Povilas Kanapickas]

On 2025-02-07 23:25, Ville Syrjälä wrote:
> On Fri, Feb 07, 2025 at 08:57:34PM +0200, Povilas Kanapickas wrote:
>> Hi,
>>
>> xf86-video-intel driver is currently cannot be compiled with released
>> versions of X server. Simple reproduction steps: create Debian Bookworm
>> container, download module sources and all required dependencies and try
>> to build.
> 
> Builds fine on my Gentoo boxes here. What are the actual issues
> you are seeing?

For the record, the build failure was some weird missing autotools
dependency causing a weird error. Redoing the test after `apt build-dep
xserver-xorg-video-intel` fixed the problem. Again, sorry for the wrong
email.

>>
>> Debian Bookworm is pretty much the least exciting configuration
>> possible. And the fact that xf86-video-intel cannot be compiled there is
>> not good.
>>
>> For almost any other driver this is not a problem, because it is
>> possible to create a merge request on gitlab.freedesktop.org. Eventually
>> simple maintenance and build-related merge requests are merged. However
>> in the case of Intel driver, merge requests are disabled and the
>> recommended way to submit patches is via intel-gfx@lists.freedesktop.org
>> mailing list. Unfortunately, patches submitted so far are ignored there.
> 
> I've not seen any patches on the list. Care to point them out?
> 
>>
>> Given that the last commit to xf86-video-intel was 22 months ago, I
>> suspect there's little interest from Intel to spend time maintaining the
>> project.
> 
> You must be looking at some stale repo. My last commit was 
> commit ce811e78882d9f31636351dfe65351f4ded52c74
> Author:     Ville Syrjälä <ville.syrjala@linux.intel.com>
> AuthorDate: Sat Mar 18 15:45:44 2023 +0200
> Commit:     Ville Syrjälä <ville.syrjala@linux.intel.com>
> CommitDate: Tue May 7 00:32:24 2024 +0300
> 
>>
>> What do you think about opening up merge requests on the repository so
>> that at least the driver can be brought back to compilable state? Does
>> anyone have other ideas how the current situation could be resolved?
> 
> I wouldn't want to deal with mrs for any high volume stuff, but
> since this only gets the occasional fix I guess it could work.
>