Mesa Eyes Pulling libdrm Into Its Codebase

[phoronix]

Phoronix: Mesa Eyes Pulling libdrm Into Its Codebase

Longtime AMD Mesa driver developer Marek Olšák has laid out a proposal to integrate the libdrm code within Mesa rather than being maintained as its own separate project...

https://www.phoronix.com/news/Mesa-PR-Pulling-In-Libdrm

[zcansi]

> Libdrm is most notably used by Windows but there's also other users of libdrm too for those needing to interface directly with Linux's DRM.

I'm sorry, what?

[kpedersen]

I'm sorry, what?

libdrm is great. Once you have the frame buffer in place, it kind of feels like programming for DOS again (ehem, the good parts).

I didn't think Windows made any use of libdrm though either.

[oiaohm]

> Libdrm is most notably used by Windows but there's also other users of libdrm too for those needing to interface directly with Linux's DRM.

I'm sorry, what?

There is a what here.

libdrm is great. Once you have the frame buffer in place, it kind of feels like programming for DOS again (ehem, the good parts).

I didn't think Windows made any use of libdrm though either.

https://gitlab.freedesktop.org/mesa/drm/-/blob/main/meson.build?ref_type=heads#L30

The reality is libdrm does not build for windows to use with Windows applications.

But there is truth to it in a very wrong way.

libdrm is used lib wslg under windows with the Microsoft d3d12 opengl driver. Of course the d3d12 driver in mesa does not work if your are not in wslg or something equal so you have to be inside Windows.

Yes libdrm is marked as used source by MIcrosoft windows so is mesa because both are used inside the wslg bit.

What do you define as windows does this include WSLg if yes then libdrm/mesa are used by Windows. If you say WSLg is something separate to Windows then libdrm/mesa is not used by Windows. Yes we have a Schrodinger cat where depend on how you look inside the box alters you answer.

[cj.wijtmans]

its the poetering disease. systemd, mesa, gcc, linux, pipewire that are monolithic and many other packages that bundle libraries into their repositories even though they have their own main repo. It mgiht be fine for the average distro that can download the mono repo, update it, disect it into pieces to release the package. For gentoo that actually handles packages properly, its kind of a nightmare. Maybe its about time the average linux user abandons this corporate crap spaghetti code.

[V1tol]

It mgiht be fine for the average distro that can download the mono repo, update it, disect it into pieces to release the package. For gentoo that actually handles packages properly, its kind of a nightmare.

I think that is a gentoo problem then, not Linux? In Arch splitting mono repo into distinct packages is as simple as defining a bash function. Thanks to that for average Arch user nothing will even change - libdrm will continue to exist, it just won't have it's own PKGBUILD but become a part of mesa build.

Maybe its about time the average linux user abandons this corporate crap spaghetti code.

And what real alternatives average Linux user has for

systemd, mesa, gcc, linux, pipewire

? I'm a simple user, I want something that is used by many people (has lot's of usecases, documentation, stackoverflow answers ffs) and not some marginal thing where you should read source code (and sometimes even patch it) to meet your expectations.

[cj.wijtmans]

I think that is a gentoo problem then, not Linux?

Improper source management is the fault of gentoo?

In Arch splitting mono repo into distinct packages is as simple as defining a bash function.

And you are wrong about arch as well. Just a quick example.

https://www.reddit.com/r/archlinux/comments/178wxrg/how_to_prevent_package_bundled_libraries_from/

? I'm a simple user

You simply dont underst and what you are talking about.

The fact distro maintainers, arch linux users and gentoo users have to apply hacks because of mono repos and bundled libraries makes it the fault of maintainers and users? Never mind that sometimes the bundled libs could divert from the main repo, the solution is to just absorb the entire code and maintain it there, screw if anyone else was using the library outside of the crappy mono repo, hard core poetering style. We now have eudev and systemd udev, making it hard for anyone else to create an alternative init system, yeah great.

[fallingcats]

The fact distro maintainers, arch linux users and gentoo users have to apply hacks because of mono repos and bundled libraries makes it the fault of maintainers and users? Never mind that sometimes the bundled libs could divert from the main repo, the solution is to just absorb the entire code and maintain it there, screw if anyone else was using the library outside of the crappy mono repo, hard core poetering style. We now have eudev and systemd udev, making it hard for anyone else to create an alternative init system, yeah great.

Please explain exactly which part of the PKGBUILD file is objectively a hack and not just like your opinion, man. I'm searious.

Your linked Reddit post has nothing to do with this, installing two different versions of the same dependency is an issue that arch just doesn't allow in general without workarounds.

[Quackdoc]

normally im not a fan of these uber package style things, but considering libdrm is tied pretty closely with mesa anyways I don't mind it. for those who want a seperate solution, minidrm is always a thing

[You-]

its the poetering disease. systemd, mesa, gcc, linux, pipewire that are monolithic and many other packages that bundle libraries into their repositories

He even invented a time machine and infected the BSD's and GNU from before he was able to even code.