xdpyinfo and xrandr can show the boundaries. Am I missing something needed to get inxi to show them?

Back to top

Checking mine, and keeping in mind that 'screen' does NOT refer to the monitor, it refers to the space that xorg is controlling as a single screen, in my case here, it's a dual monitor 'screen':



I was curious where they got the mm size, but it's simple:

2560/96 * 25.4 == 677mm

Note that in my case, my two monitors are different sizes, but have the same pixel resolution.

I'm not sure if this is what you mean when you use the term 'boundaries' but that's the only thing I see.

In my case, the 271mm does in fact correspond to the physical height of one of the monitors, but not of the other one.

So the 'screen' value is of no actual utility as far as I can tell, it might now and then correspond to the actual dimensions of the screen, and it might not.

The connected values however are more promising:


And those do in fact appear to give the actual monitor size as far as I can tell. Note that one could also get the diagonal of those two sides to get the 'inch' size of the monitor.

Logically however, information about screens in the physical sense are difficult to locate in this output since the Device-x lines are about the graphics cards / chips located, but right now, it's treated more as a function of Xorg server than of your actual monitors in a physical sense. I guess I could make it a 'Monitor' line or something like that. As hardware, obviously it would be desirable to locate what the hardware is.

note that none of this stuff will work in wayland, but as long as wayland relies on xwayland, it will keep working, more or less.

Xorg.x.log does have this information in it, which makes me wonder if that info is located somewhere else as well. but it's hard to match a monitor to its pixel / mm dimensions.

Note that there's actually two additional bits of info available, dpi and mm dimensions.

The easiest would be to just integrate the extra dpi/mm info into the existing output, though more could be grabbed I think. Note that the way xrandr refers to the monitors is different from the way that Xorg.x.log refers to them, so it's hard to match the two. If I could, I could actually get the monitor name as well.
Back to top

I've taken a closer look at this, and did a test case in pinxi, but the output really isn't good, there's too much, and would require basically doing a rewrite of the logic there a bit.

There's also a problem with the source, because I'm using xrandr for this, if a user has two gfx cards and uses one per monitor, that results in two logical screens, not one, I think anyway.

This has always been a weakness of inxi graphics.



I'd have to rewrite the core logic to pull out all those parts, and make it handle screen 1, 2, etc.

That's an xorg screen, not your hardware screen.

Right now it has some real limits, it only shows advanced resolution data on single screen systems, that's an xorg screen, again, not your physical screens.

That's because the advanced stuff comes from xrandr, not xdpyinfo, and I'd have to run xrandr multiple times for > 1 virtual screen systems, which would be a real pain, and I don't have any real data for that. That would further require rewriting the logic there, and rewriting the output logic as well since I'd have to store the data in a much more granular way.

This is all because the "resolution:" item is basically a hack, has always been a hack, so to really deal with it, I'd have to make it not a hack anymore, which would take some work.

I may or may not do that, but I'm lacking in dev systems that are set up for > 1 virtual screen, and it would be hard to figure out how to do that without a real dev system I could use to recreate the more complicated scenario.

Anyway, the above isn't going to be retained, it's too ugly and hackish, I may keep the dpi item though since that's pretty simple.
Back to top

For my own purposes, I'm adding these as notes:

xdpyinfo will show technical display :0 to :x

xrandr by default shows only information from the current display, so a full solution would require all the displays running, which xdpyinfo can supply.

To build up the data properly, I'd have to refactor that logic, which is a good idea anyway since it's such a hack in the first place, to use arrays of hashes, with full granular data types.

Each 'display' has 'screens', from 1 to more.

the string: :0.0 means, screen 0 of display 0 [:[display].[screen]]

:0.1 would be screen 1 of display 0.

Once all the displays were stored, there would be a per display array of 'screens'. Note that for xorg, a single display and screen is just a trivial case of what can happen. I do not know what happens with wayland systems running xwayland though, I would guess its' a simpler system and syntax, but I don't know. Wayland I assume basically is written from the ground up to be a single display running a single screen, but I do not know that either for sure, but I'm guessing, since the complexity of running > 1 displays with > 1 possible screens per display is I think part of why wayland was created, but I'm not sure about that, but I think that's the security issue, when > 1 displays are running, another display could grab data from the primary user display, or something like that.

So basically inxi would need to collect the display number/id, the screen number/id

In theory I have samples of this in user datasets if I can just find one with either > 1 display or > 1 screen in xdpyinfo so I know what it looks like.

Note that for xdpyinfo, a 'screen' is the logical whole of what you see, not x monitor screens treated each as a screen. display 0 could have 2 screens, :0.0 and :0.1, for example.

I doubt I can actually find any user datasets that have > 1 display running, but the logic I think would be smart enough to 'know' what it's looking at.

There's a certain fruitlessness to redoing all this because wayland is slowly creeping up on us, but it's so slow that, as with perl 5 > 6, eventually perl 6 just became a new perl, and perl 5 remained the active perl branch, which is how it's stayed more or less.

Once the arrays of data were created in this way, it's possible to do per screen printouts, and actually making the stuff reflect what is really is to xorg, which would be odd in a sense because it might not be what it is to normal users in terms of how they think of their display and screen.

A screen is a member of the set of screens that can be run by one display. A display is a member of the set of displays that can be run by an xorg server.

Each screen, or display, I'm not sure which, is then shown one at a time by xrandr to get the full info, which in this case is really just adding the per physical screen pixels and frequencies.

This feature currently only works for single 'screen' systems, which is why it's only used xrandr when only one 'screen' was found.

The main question is if I start fixing this up now and hold off the coming 3.1.0 release, which contains at least one critical bug fix, or put this off and do it as a 3.1.1 fix. The latter is probably the better idea I think.

Some of the internal uses of 'screen' vs 'display' may be confused, so I will at least fix those since they cause confusion and make the code hard to read and understand.

I believe though I'm not certain that xrandr in fact shows all screens from the display running xrandr, but it's just because normally you are using :0.0 or :1.0 in the case of gdm on arch linux.

I further believe that Xorg.0.log logs data from display 0, and Xorg.1.log from display 1, not from the sub screens contained in each display, I will have to double check that.

In a sense, the fix would mirror the set of fixes that ended up creating the xorg driver section, with failed, unloaded, etc, similar data structure except simpler of course.
Back to top

More notes;

I checked all user datasets, and aside from the Display :1 item created by gdm in some systems, NO user datasets have ever contained any screen other than #0.

I believe this is one thing lying behind the wayland project, simply dumping all the logic at once that supported remote x servers creating desktops for work station dummy systems. This is also why ssh X forwarding does not work and will never work with wayland, if I understand it right.

So technically I'd end up with basically a complicated data structure that could in theory support > 1 displays with > 1 screens per display, but which in practice would in almost all cases simply support 1 display with 1 screen.

That helps define the problem decently I think.
Back to top

First draft, still have to assign the data to different -x and -a levels, and make metric/imperial conversions, but that's the general idea:



This required a full rewrite of the logic, but as noted, that logic was always a total hack anyway.
Back to top

screenshot of 3 display, single Xorg "screen" 3640x2640 desktop with incorporated configurations:

susepaste.org/81396694
Back to top