On my system there seem to be three interfaces:
Only card0-VGA-1 has a status entry and it says "connected". So what the heck does that mean? And what are the other two?

The VGA-1 display device is what is relevant here.

Edit: The thread has moved on and I can't even see who was asking....but it wasn't meant for you. Someone was just wanting to know how to identify the display device name.

By the way, re identifying the display port ID, it's not as easy as just looking at /sys/class/drm and xrandr. Why? because each and every X.org display driver is free to adopt whatever transformations they want to the name. At one point, we actually found the code for how amdgpu alterred the port ID string. I'd say this is a good example of the somewhat chaotic and counter-productive nature of the X.org stack.

One of the only types that tends to be fairly easy to map is VGA ports, mainly because there are usually only 1, max 2, and also because those are all so old that the weird mapping transformations seem to be limited to changing the ID number, say, drm VGA-1 to X display port ID VGA-0, VGA0, VGA-1, VGA1, VGA (and probably other variants).

For inxi purposes, this forced me to add many hacks to tentatively match the drm port ID value with the X port ID value.

It was only after a few years that I finally discovered that there can be an actual static ID that is available, it's a unique identifier and is found in the /sys data and if you use the right option, in xrandr.

With xrandr --prop, it's the
CONNECTOR_ID: 55
item, which has a corresponding match in /sys/class/drm/*/connector_id

This took me years to find, and created the first time I could actually conclusively match a drm port ID to the xrandr port ID. I am pretty certain that this issue does not exist in wayland compositors since they use the drm gpu driver directly, without the X.org display driver layer added ontop.

Wny it was ever allowed to have the drm ID string not be forced to match the x display driver port ID string is beyond me, but it led to years of confusion and difficulty in diagnosing complicated monitor layouts.

This method is not 100% reliable however, and of course falls apart when there is no DRM driver, or under various other circumstances.

I believe the amdgpu code we found was so clear that literally any syntaxi could be generated by any X display driver that I realized it would be absurd to try to do a 1 by one x display driver monitor port ID transformation sequence.

Where it really fell apart totally was complex DisplayPort IDs, which vary so widely in many cases inxi could not ever match the monitor x display ID to the kernel drm port ID at all, there was simply no rule possible that would capture those.

The connector_id mapping thankfully finally gave a 'good enough' solution that 'usually works'.

If I'm going to put on my Wayland advocate hat, which you will rarely find me wearing, this exact situation, the total lack of control over the mapping of the port ID name string to the DRM name string was an indication of the internal issues in the X.org project. Note that the --prop argument was not always available, so inxi has to test to see if that generated an error to use it, then fallback to the old method, which is no arg for xrandr.

If you want to read a sort of bookend to this thread, check out this https://lwn.net/Articles/961899/#Comments which dips into many similar areas, from slightly different starting questions, but the overall comments will be educational, and somewhat familiar.

My personal favorate was: https://lwn.net/Articles/962914/
I think this was a bit less forgiveable an error on lwn.net since it tends to focus around linux kernel developers, who should really know better than this, but it does highlight the ongoing confusion of concepts.

This person, for example, seemed to believe that there is a wayland display server that should support xfce4, and that this display server must have been somehow been shipped with the Pi 5 OS img he grabbed, and thus because that wayland display server did not support xfce4, xfce4 did not work. That thread is indicative of how people who really should know better still don't.

As with this thread here, however, there are many useful tidbits and comments that help pad out the overall understanding of the x11/wayland - [X display servers]/[Wayland compositors] that I found really helpful, particularly when it was noted the other X display servers that are still actively developed.

However, for me, this is all neither here nor there, to me, the real question is if the Tiny Linuxes, like TinyCore and Siitaz, will be able to build a stack on newer kernels with a tiny wayland compositor and still come in at their very slim fighting weights of 15 to 50 MiB install iso. To me, if they can dump the Xvesa layer, and fully leverage the kernel drm gpu drivers, this should allow for a tiny stack, but it may also be that the new wayland based tools, terminals, toolkits, etc, are so bloated and massive now that this goal might be impossible to meet.

3 members found this post helpful.

I finally got a round tuit and set up a new slackware-current-15.1 on my rather old desktop with an i915 intel graphics (that runs current Xorg perfectly) : lspci output for this card at bottom.

Firstly, my understanding about running a wayland infrastructure on a slackware is that there are two significantly different approaches, which I think of as :
"native" - start up a wayland-enabled desktop environment with no software other than the drm kernel module currently controlling the graphics card. (I chose KDE) All graphical apps are to be launched from within this desktop environment.
reference : https://www.linuxquestions.org/quest...ne-4175695918/
"emulation" - start up a Wayland compositor to run the Xwayland server, and then run my Xorg-aware window manager (sawfish) under that. graphical apps should roughly think they are using an Xorg server.
reference : https://docs.slackware.com/howtos:wi...ts_in_xwayland

Is that understanding even close? Anyway, for my first ever attempt at doing anything wayland, I went ahead with "native" on the basis that I would learn more by interacting with the real wayland protocol.

So, from the root login console, with drm and i915 kernel modules loaded, I ran
The result was about 8 messages written to stdout, (unfortunately now lost because ...) then a switch to (I Presume) vt7, a sharp-end-of-a-spear graphical cursor appearing, and then - total loss of response to all mouse/keyboard actions.

Fortunately the system itself is still running and I had taken the precaution of starting an emacs session to a (different!) Xorg server, so I was able to view the following messages in /var/log/messages

I searched on the internet and found a few hits but none led to anything conclusive. Most turned out to be because of presence of an NVIDIA card - there is no Nvidia on my system.
I also saw a reference to the "wayland session log" located at either /var/log/wayland.0.log or ~/.local/share/sddm/wayland-session.log, but neither of those exist on my system.

Can anyone offer any advice?

Cheers John

My apps are mostly native Wayland. Those that are not use XWayland. XWayland is just a translator that takes X apps that do not speak Wayland and convert the calls into Wayland calls. XWayland does not slow down X apps much, and is not even a factor in Wayland aware apps.
BUT: I am not running Slack!

1 members found this post helpful.

Unfortunately, Wayland/Plasma5 sessions, just like Plasma6 or other sessions under a Wayland compositor, require at least OpenGL 2.0 support to function properly.

But your GMA500 graphics only support OpenGL 1.4, so your computer does not fulfill the hardware requirements for Plasma5 sessions under Wayland.

Which means that sooner or later, this computer of yours will only be capable of running Linux console sessions.

1 members found this post helpful.

Plasma sucks the same on both X and wayland.. with that class of hardware it's no gain no loss.
Xfce team at least announced both X and wayland will be supported in the future.
So I guess take this FUD of yours to fedora forum or something, unless you have evidence X/Xfce in slackware will get dropped "sooner or later".

This does not matter much, because all Wayland compositors require at least OpenGL 2.0, so it is not something specific to Plasma5 or Plasma6.

XFCE's plans don't matter much, because if RedHat/IBM stops maintaining Xorg and the major distros abandon Xorg, a ton of unfixed Xorg security issues will soon be public, making its inclusion in Slackware, or any other minor Linux distribution, a big Safety problem.

And I don't see Slackware maintaining Xorg, because it simply doesn't have many C/C++ programmers associated with it.

However, the abandonment of Xorg by RedHat/IBM will not mean the end of XFCE or Fluxbox under X11, because as discussed in other forums, they will probably set up a method to have full-screen X11 sessions under Xwayland, as a client to a simple composer Wayland, like Weston. Something like Xweston, which already exists.

But this X11 server built on top of a Wayland composer will require at least OpenGL 2.0 support, which has been available anyway since Core2 Duo motherboards were released. That's why unfortunately, our friend John Lumby will not be able to benefit from this solution, because his computer only supports OpenGL 1.4

As I already said, I don't think that Slackware or any other minor Linux distribution will maintain Xorg after it is abandoned and its security issues will tighten.

If we look realistically at the future, probably Slackware will adopt a solution based on Xwayland full-screen X11 sessions as a client to a Wayland composer, a solution that can be maintained. Which technically will mean a requirement to have at least OpenGL 2.0 to be able even to run XFCE or Fluxbox.

2 members found this post helpful.

The desktop team (who develop and support X.ORG and Wayland) have said that there is no plan to drop support for X.ORG. They have shifted development over to Wayland going forward, but are still porting fixes back into X.ORG where appropriate or required to maintain security. X.ORG is not getting new FEATURES, but does it really need any?
I expect X.ORG will be usable by the distributions that want or need to stay on X.ORG for another two decades, possibly much longer.

3 members found this post helpful.

By 'Xwayland' you mean emulating Xorg on top of wayland? So, same issues/vulnerabilities as before, but with few extra bugs added.
As I already noted few pages before: until NVIDIA ports the driver configuration to wayland protocol and achieves feature parity, I don't see this going anywhere.
And I say this not because I like NVIDIA, but because they are the largest GPU vendor at least in EU. You expect them to drop hundreds of features?
Until you show me evidence that features they've used "xorg.conf" for, 20 years ago or more, are supported by wayland or weston or whatever, then I will believe you wayland's ready.
Otherwise, it's FUD. Slackware was not RedHat derivative, last I checked. And Xorg is still used on few non-linux systems also, none of which currently depend on RedHat's deprecation policy.

1 members found this post helpful.

Thank-you ZhaoLin1457 for your diagnosis of my problem and other very informative comments. Which have got me thinking - always dangerous And I have ended up with a couple more questions :


1. You refer to hardware requirements for Wayland compositors, and strangely that piece of text in your comment is underlined as though it is a clickable URL, but it isn't - so I googled "hardware requirements for wayland compositor" - and found - lots of pages, *none* of which stated hardware requirements, only software package support and dependencies! So - what are they? and where are they stated?

2. Specifically to my admittedly rather old workstation - although you say "his computer" did you mean "his VGA card"? This computer has a D945GCLF2 motherboard with the on-board Intel Graphics VGA adapter I showed and which I think is what lacks the OpenGL-2.0 (?). It also has a PCI-X slot - what if I put this in that slot :
MATROX Parhelia 256MB PCI-X PCI Video Graphics Card MGI PH-P256PDIF
used one advertised for US$169 on E-bay. Appears to have DVI and VGA sockets. Note that I care nothing about performance, this is just for experimentation. Does this card on this computer satisfy the aforementioned "hardware requirements for ... wayland" whatever they may be?


Cheers, John

@John Lumby
Don't fall for the ebay scam, you can get a brand new card with 4GB video ram for something like 80 bucks.
Just search the store for something to be used in office/workstation setup, and not in gaming/mining.

2 members found this post helpful.

Thanks elcore. Yes, if only ... But any such card will be PCIe, which for my machine would then also require a PCI-X card with PCIe socket adapter suitable for graphics attachment - if there even is such a thing. There is only the one PCI-X slot free. Although this is an old machine, circa 2011, wayland itself is even older, so surely there must have been some graphics card which supported wayland back then? I don't have any other computer that I can use for experiments like this.

Cheers, John

Not sure about your board, but 2011 board should have a "PCI-E 2.0" slot, which is sometimes unsupported by new cards but physically the same as new "PCI-E 3.0" slot.
Some newer cards circa 2020-2022 support both 2.0 and 3.0, it's usually noted on the box.

Buying old 2.0-only card is not recommended because then you're basically paying the "antique tax" so it's more expensive than the new one.
They charge more, because it's no longer manufactured, and considered a rare spare part for old machines.

TBH, the spare part situation reminds me of those doomsayers in this thread hating on Xorg, calling it dinosaur, etc. Guess we're gonna get charged more now, to be able to run Xorg lol.
And, annoyingly enough, they using the exact same tactic as systemd apologists:
"bash=insecure so we gonna push this in-house OS between the kernel and bash to make bash look secure, even though it's still not"
"alsa=insecure so we gonna push this sound server between the kernel and alsalib to make alsa look secure, even though it's still not"
"xorg=insecure so we gonna push this new protocol between the kernel and xorg to make xorg look secure, even though it's still not"

1 members found this post helpful.

the pci-e spec is supposed to be backward compatible. Most current cards should work on a pci-e 2.0 system. Some lower end cards might not because they tend to rely on power from the slot and 2.x systems mostly date from a more civilized time where GPUs did not draw hundreds of watts. Higher end cards might require power supply connectors you don't have in an older chassis, but as long as you have a PSU that can deliver the watts you have all the correct voltage rails coming off any ATX unit so you can 'fix' that if you are handy.

The performance may be limited if you can't give it enough lanes. Keep on mind real throughput of pci-e 2.0 vs a 3.0 slot is something like 40%.

2 members found this post helpful.