-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have a box with Debian Wheezy and TDE installed in it. The GPU has three connectors, one DVI and two HDMI.
I have two monitors connected to it. The diagonal measurement of one is 49 cm. It has a 1600x900 resolution and is connected to the box by a DVI cable.
The other is a TV/monitor with a diagonal measurement of 124 cm (49 inches). It is connected to the box by HDMI. The box recognizes its existence, but the display on it has the same resolution as the smaller monitor.
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen. It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
Is it possible to create a display resolution larger than 1600x900 for the large monitor and properly centred on the screen, possibly using the ‘Monitor and Display’ feature of the TDE Control Centre?
Regards, Ken
I'm using two 21" CRT displays, one connected to my notebook's dock's VGA, second to DVI using DVI-HDMI converter and HDMI-VGA converter. Then only VGA-Sun cable is connected to monitor. In my case, having such "adapter ladder" makes system forget about monitor's default modes, obtained in Linux by VESA digital signals. To fix the problem, I have a shell script which starts when my laptop is docked or starts docked. This script consists of xrandr commands, like: - Turn off notebook's internal display - Turn VGA monitor on - Insert modeline to DVI. - Turn on DVI, right of VGA. - Select resolution from inserted modeline. Personally I couldn't fix the problem in any GUI solution, or without modelines. MCbx
Ken Heard kenslists@teksavvy.com napisał(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have a box with Debian Wheezy and TDE installed in it. The GPU has three connectors, one DVI and two HDMI.
I have two monitors connected to it. The diagonal measurement of one is 49 cm. It has a 1600x900 resolution and is connected to the box by a DVI cable.
The other is a TV/monitor with a diagonal measurement of 124 cm (49 inches). It is connected to the box by HDMI. The box recognizes its existence, but the display on it has the same resolution as the smaller monitor.
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen. It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
Is it possible to create a display resolution larger than 1600x900 for the large monitor and properly centred on the screen, possibly using the ‘Monitor and Display’ feature of the TDE Control Centre?
Regards, Ken
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlZ5CF4ACgkQlNlJzOkJmTdnSQCeJh8VQhZSvohCbt0/1l3nR9Ll 984An0Y3kHc/uEu/cREaZtH9Mct0S9Qo =bBdu -----END PGP SIGNATURE-----
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-12-22 16:34, iadest@o2.pl wrote:
I'm using two 21" CRT displays, one connected to my notebook's dock's VGA, second to DVI using DVI-HDMI converter and HDMI-VGA converter. Then only VGA-Sun cable is connected to monitor. In my case, having such "adapter ladder" makes system forget about monitor's default modes, obtained in Linux by VESA digital signals. To fix the problem, I have a shell script which starts when my laptop is docked or starts docked. This script consists of xrandr commands, like: - Turn off notebook's internal display - Turn VGA monitor on - Insert modeline to DVI. - Turn on DVI, right of VGA. - Select resolution from inserted modeline. Personally I couldn't fix the problem in any GUI solution, or without modelines. MCbx
All of which raises the question: "What is the "Monitor and Display" option in the TDE Control Centre is for?"
Ken
On Tue, 22 Dec 2015 20:21:24 +0700 Ken Heard kenslists@teksavvy.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-12-22 16:34, iadest@o2.pl wrote:
I'm using two 21" CRT displays, one connected to my notebook's dock's VGA, second to DVI using DVI-HDMI converter and HDMI-VGA converter. Then only VGA-Sun cable is connected to monitor. In my case, having such "adapter ladder" makes system forget about monitor's default modes, obtained in Linux by VESA digital signals. To fix the problem, I have a shell script which starts when my laptop is docked or starts docked. This script consists of xrandr commands, like: - Turn off notebook's internal display - Turn VGA monitor on - Insert modeline to DVI. - Turn on DVI, right of VGA. - Select resolution from inserted modeline. Personally I couldn't fix the problem in any GUI solution, or without modelines. MCbx
All of which raises the question: "What is the "Monitor and Display" option in the TDE Control Centre is for?"
The old KDE3 module contained a "screen" droplist for configuring individual monitors--has this changed? (I only have single-monitor systems available right now.)
Another option, if and only if your computer's video card uses an nVidia chipset, is to install the manufacturer's proprietary driver module and configuration utility, which offers extended support. I don't know if AMD offers an equivalent. Intel almost certainly doesn't.
E. Liddell
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-12-22 22:59, E. Liddell wrote:
The old KDE3 module contained a "screen" droplist for configuring individual monitors--has this changed? (I only have single-monitor systems available right now.)
This is the first time I have had to deal with a multi monitor situation, but with recent changes such as TV over the internet I know it will not be the last.
Another option, if and only if your computer's video card uses an nVidia chipset, is to install the manufacturer's proprietary driver module and configuration utility, which offers extended support. I don't know if AMD offers an equivalent. Intel almost certainly doesn't.
The chipset I have in this computer is an Intel. I found out soon enough that Intel does not.
Ken
Ken Heard composed on 2015-12-23 09:52 (UTC+0700):
Another option, if and only if your computer's video card uses an nVidia chipset, is to install the manufacturer's proprietary driver module and configuration utility, which offers extended support. I don't know if AMD offers an equivalent. Intel almost certainly doesn't.
The chipset I have in this computer is an Intel. I found out soon enough that Intel does not.
Intel provides no proprietary driver because its people write the FOSS driver code. If you're interested in how that works, check out the intel-gfx mailing list.
Ken Heard wrote:
The chipset I have in this computer is an Intel. I found out soon enough that Intel does not.
Hi Ken, it is a bit frustrating to configure Intel card with two different monitors. It was even more difficult in the past, but things are getting better now.
You could try the easy way - use live ubuntu and check if it works there. Use the Xorg command to get the xorg.conf and secure the log files.
When I got my Dell 5440 notebook (and nothing was working as it should). I did following to get X running
lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
This told me which chip and version was built in. Now you can start with Xorg setup
Xorg --help
... -configure probe for devices and write an xorg.conf
...
then run
Xorg -configure
or perhaps
Xorg :1 -configure
if you already have one running on :0
you will get xorg.conf.new file in the directory you execute it
This is a good starting point to get xorg.conf with your relevant parameters and variables
I ended up putting the modelines in to the config file per monitor like this (careful linebreaks because of mail whatever). I think I took them from the log file testing each output separately. Be careful, what is good for me might not be good for you, so this is just a sample.
Section "Monitor" Identifier "eDP1" VendorName "Dell" ModelName "Built in Display" Option "DPMS" Option "Primary" "true" Modeline "1366x768@60" 70.50 1366 1414 1446 1456 768 773 778 807 +hsync -vsync Modeline "1366x768@40" 47.00 1366 1414 1446 1456 768 773 778 807 +hsync -vsync Modeline "1360x768@59.8" 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync Modeline "1360x768@60.0" 72.00 1360 1408 1440 1520 768 771 781 790 +hsync -vsync Modeline "1024x768@60.0" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync Modeline "800x600@60.3" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync Modeline "800x600@56.2" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync Modeline "640x480@59.9" 25.18 640 656 752 800 480 490 492 525 -hsync -vsync EndSection
Section "Monitor" Identifier "DP2" VendorName "External" ModelName "External Display" Option "DPMS" Option "RightOf" "eDP1" Modeline "1920x1080@60.0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "1600x1200@60.0" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync Modeline "1680x1050@59.9" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync Modeline "1400x1050@59.9" 101.00 1400 1448 1480 1560 1050 1053 1057 1080 +hsync -vsync Modeline "1280x1024@75.0" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync Modeline "1280x1024@60.0" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync Modeline "1440x900@59.9" 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync Modeline "1280x960@60.0" 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync Modeline "1152x864@75.0" 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync Modeline "1024x768@75.1" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync Modeline "1024x768@70.1" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync Modeline "1024x768@60.0" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync Modeline "832x624@74.6" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync Modeline "800x600@72.2" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync Modeline "800x600@75.0" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync Modeline "800x600@60.3" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync Modeline "800x600@56.2" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync Modeline "640x480@75.0" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync Modeline "640x480@72.8" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync Modeline "640x480@66.7" 30.24 640 704 768 864 480 483 486 525 -hsync -vsync Modeline "640x480@60.0" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "720x400@70.1" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync Modeline "640x400@70.0" 23.35 640 656 720 800 400 401 404 417 -hsync +vsync
EndSection
in the Section "Device"
Option "AccelMethod" "uxa" Option "DRI" "on" Option "HotPlug" "on" Option "ReprobeOutputs" "on"
Identifier "Card0" Driver "intel" BusID "PCI:0:2:0"
Section "ServerFlags" Option "AllowEmptyInput" "on"
Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor-eDP1" Monitor "Monitor-DP2" #RightOf "Monitor-eDP1"
Section "Module" Load "glx" Load "synaptics" Load "evdev" # http://wiki.ubuntuusers.de/XServer # http://wiki.ubuntuusers.de/RandR Load "i2c" Load "dri2" Load "dbi" Load "bitmap" Load "ddc" Load "extmod" Load "freetype" Load "int10" Load "type1" Load "vbe" EndSection
I hope this will give you some ideas on what to try with.
regards
deloptes composed on 2015-12-24 01:11 (UTC+0100):
I ended up putting the modelines in to the config file per monitor like this (careful linebreaks because of mail whatever). I think I took them from the log file testing each output separately. Be careful, what is good for me might not be good for you, so this is just a sample.
I've NEVER EVER needed to put any modeline in any distro's xorg.conf, and I do a LOT of testing with different distro versions, Xorg versions, CRT and LCD displays, gfxchips and video drivers. Xorg calculates the modelines it needs if it has any valid data about the hardware. Usually EDID is sufficient. When not (e.g. invalid EDID), all it needs is the display's HorizSync and VertRefresh ranges, and the desired resolution.
IOW, don't waste your time on modelines unless you like wasting more time on an already tedious task, or you've tried absolutely everything else, without success.
I've NEVER EVER needed to put any modeline in any distro's xorg.conf, and I do a LOT of testing with different distro versions, Xorg versions, CRT and LCD displays, gfxchips and video drivers. Xorg calculates the modelines it needs if it has any valid data about the hardware. Usually EDID is sufficient. When not (e.g. invalid EDID), all it needs is the display's HorizSync and VertRefresh ranges, and the desired resolution.
Well, not always. I found some combinations of displays and vieo cards making the system not read EDID/DDC. The rule is: If there is any problem with DDC/EDID, go with modelines. Another good thing with modelines is that if you have monitor with proprietary software to move and resize screen, you can compensate lack of it using modeline. An example of DDC incompatibility problem is Cordata monitor (800x600 only) and GeForce FX 5200. It starts with 1280x1024 resolution. If monitor is connected to my notebook (Intel 950), it is detected properly. If another monitor is connected to GeForce, everything is OK. Only this single particular combination, Cordata connected to GeForce, doesn't work. MCbx
iadest@o2.pl composed on 2015-12-24 11:40 (UTC+0100):
I've NEVER EVER needed to put any modeline in any distro's xorg.conf, and I do a LOT of testing with different distro versions, Xorg versions, CRT and LCD displays, gfxchips and video drivers. Xorg calculates the modelines it needs if it has any valid data about the hardware. Usually EDID is sufficient. When not (e.g. invalid EDID), all it needs is the display's HorizSync and VertRefresh ranges, and the desired resolution.
Well, not always. I found some combinations of displays and vieo cards making the system not read EDID/DDC.
So did I. And in every case, providing Xorg with HorizSync and VertRefresh ranges, and desired resolution (PreferredMode in server versions since it was created; previously, and currently with non-KMS drivers via 'Subsection "Display"'s 'Modes'), provided all that was needed.
The rule is: If there is any problem with DDC/EDID, go with modelines.
Again, Xorg's built in modeline calculator works as well as gtf or cvt, and does so automatically, so manual modeline generation should be an absolute last resort only when all else fails. Manual calculation is an absolute and complete waste of time otherwise.
deloptes composed on 2015-12-24 01:11 (UTC+0100):
I ended up putting the modelines in to the config file per monitor like this (careful linebreaks because of mail whatever). I think I took them from the log file testing each output separately. Be careful, what is good for me might not be good for you, so this is just a sample.
I've NEVER EVER needed to put any modeline in any distro's xorg.conf, and I do a LOT of testing with different distro versions, Xorg versions, CRT and LCD displays, gfxchips and video drivers. Xorg calculates the modelines it needs if it has any valid data about the hardware. Usually EDID is sufficient. When not (e.g. invalid EDID), all it needs is the display's HorizSync and VertRefresh ranges, and the desired resolution.
IOW, don't waste your time on modelines unless you like wasting more time on an already tedious task, or you've tried absolutely everything else, without success.
deloptes composed on 2015-12-24 01:11 (UTC+0100):
...you can start with Xorg setup
Xorg --help
... -configure probe for devices and write an xorg.conf
...
then run
Xorg -configure
OP is running Wheezy. Wheezy is like most distros of the Xorg automagic years. Its 'Xorg -configure' generates an xorg.conf loaded with litter unrelated to solving multihead trouble or any other kind of video trouble, and virtually nothing useful in actually generating a usable multihead config.[1] It's a skeleton that needs to be heavily stripped, and then extensivly built upon. A completely generic skeleton or template provides a better starting point for self-construction of a working multihead configuration.[2]
[1] http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.conf.wheezynew-fromXorg-configure [2] e.g. http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1600x1200under-digi1600x1...
Hi appreciated your arguments
OP is running Wheezy. Wheezy is like most distros of the Xorg automagic years. Its 'Xorg -configure' generates an xorg.conf loaded with litter
Some newer Intel chips _do_not_ work with the older Xorg and it is recommended to get the newer drivers and X software. Perhaps it would be easier for OP to upgrade.
By not working I mean - for one display it works, but all the rest doesn't. Perhaps OP should check if Xorg in the version (s)he uses supports the hardware properly.
regards
deloptes composed on 2015-12-24 09:56 (UTC+0100):
Hi appreciated your arguments
OP is running Wheezy. Wheezy is like most distros of the Xorg automagic years. Its 'Xorg -configure' generates an xorg.conf loaded with litter
Some newer Intel chips _do_not_ work with the older Xorg and it is recommended to get the newer drivers and X software. Perhaps it would be easier for OP to upgrade.
By not working I mean - for one display it works, but all the rest doesn't. Perhaps OP should check if Xorg in the version (s)he uses supports the hardware properly.
Regarding OP's gfxchip, I'm pretty sure I did that for him. We're both using rev 06 Haswell, which works in Wheezy for me just fine with 1680x1050 and 1920x1080 displays. He should be able to use the same xorg.conf I shared if he changes its 1680x1050 to 1600x900, unless there's an EDID or cabling problem with his 1600x900 device. This should be simpler than upgrades intended for newer gfxchips than what we have which are unlikely to be relevant to manually configuring multihead for hardware design approaching 3 years of age. Manual Xorg configuration is intimidating enough the first time needed without adding upgrading to the process.
Ken Heard wrote:
All of which raises the question: "What is the "Monitor and Display" option in the TDE Control Centre is for?"
Ken
AFAIR screen is related to GPU (in contrast to virtual screen). Monitor does not require explanation. It is what it is. Display is what is displayed on the Monitor at a time - you can have more displays and switch between them on the same monitor.
So usually you have one card with one screen and one or more monitors that are handled by the X server. The display part is done by the desktop you use. You could also install multiple cards with multiple outputs you would have more screens and monitors.
I hope this helps
Ken Heard wrote:
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen. It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
On some graphic cards it is not possible to scale the size per output. This means that you are forced to stick to the same resolution on all outputs. This is great if you have same type of monitors, but not else. As result you are forced to use the lowest common resolution provided by the end device (tv, monitor etc). If you select higher resolution than supported you can either configure the image to be fixed (so you do not see or use all of the screen) or slide.
However some tv sets provide the option to scale the image to full screen (look for format and set to custom - usually it is auto). Perhaps this will be the best for your case.
regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-12-22 17:50, deloptes wrote:
Ken Heard wrote:
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen. It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
On some graphic cards it is not possible to scale the size per output. This means that you are forced to stick to the same resolution on all outputs. This is great if you have same type of monitors, but not else. As result you are forced to use the lowest common resolution provided by the end device (tv, monitor etc). If you select higher resolution than supported you can either configure the image to be fixed (so you do not see or use all of the screen) or slide.
However some tv sets provide the option to scale the image to full screen (look for format and set to custom - usually it is auto). Perhaps this will be the best for your case.
I just now looked at the TV/monitor picture options. There is a ‘full wide screen’ option which something somewhere does not allow me to use. There is also a ‘zoom’ option. Tweaking that option allows using 80% of the screen which is better than 40-50% I suppose.
Ken
Hi Ken,
I do it in the following way:
I have two scripts in /etc/trinity/tdm
1st script - name xrand.sh ####################################################################### #!/bin/sh # usage: xrand.sh start|stop | Monitor-Typ
case "$1" in stop) /usr/bin/xrandr --output VGA1 --off ;; X193W) # for an Acer x193W /usr/bin/xrandr --output VGA1 --mode "1440x900" --left-of LVDS1 \ --output LVDS1 --mode "1024x768" ;; L1800P) # for an LG Flattron L1800P mit identischer Auflösung wie Laptop /usr/bin/xrandr --output VGA1 --mode "1024x768" --right-of LVDS1 \ --output LVDS1 --mode "1024x768" ;; text) # LG Flattron L1800P rotated for work with text documents /usr/bin/xrandr --output VGA1 --mode "1280x1024" --rotate left \ --left-of LVDS1 --output LVDS1 --mode "1024x768" ;; *) echo $0 stop | X193W | L1800P | text ;; esac ########################################################################
The 2nd script - name getMonitor.sh ######################################################################## #! /bin/bash
# x193w and l1800p are the names of the motiors written out in # Xorg-log-file
grep -i x193w /var/log/Xorg.0.log > /dev/null
if [ "${?}" == "0" ] then # found Acer monitor - set resolution /etc/trinity/tdm/xrand.sh X193W exit fi grep -i l1800p /var/log/Xorg.0.log > /dev/null if [ "${?}" == "0" ] then # LG 1800P fund - set resolution /etc/trinity/tdm/xrand.sh L1800P exit fi ########################################################################
This scripts will be called from Xstartup also located in /etc/trinity/tdm. The skript starts with:
#! /bin/sh # Xstartup - run as root before session starts
if [ -e /etc/trinity/tdm/getMonitor ]; then /etc/trinity/tdm/getMonitor fi ....
So what does it do? On startup it looks, if the acer (or the LG) is conneted to my lenovo laptop, and if so the wantet resolution and screen-positon (left or right of) will be set.
After that you can see multi monitors in trinity contol center.
Hope that helps and merry christmas and a happy new year
Rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thank you Rolf for your scripts. I had gotten as far to find out what xrand does but not (yet?) how to use it. Thanks to you I now have three examples of how to use it. These will help me next year when I figure out how to use it for my monitors.
Compliments of the season.
Ken
Ken Heard composed on 2015-12-22 15:22 (UTC+0700):
I have a box with Debian Wheezy and TDE installed in it.
So do I. :-)
This is its motherboard: http://us.msi.com/product/motherboard/B85-G41-PC-Mate.html
What's yours? At least, tell which chipset and video you have via lspci output.
The GPU has three connectors, one DVI and two HDMI.
Mine has one each of VGA, DVI and HDMI.
I have two monitors connected to it.
Again do I. :-)
The diagonal measurement of one is 49 cm. It has a 1600x900 resolution and is connected to the box by a DVI cable.
Diagonal of my 1680x1050 connected via VGA cable is 56cm.
The other is a TV/monitor with a diagonal measurement of 124 cm (49 inches). It is connected to the box by HDMI.
Diagonal of my 1920x1080 connected by DVI to PC and HDMI to TV is 80cm.
The box recognizes its existence, but the display on it has the same resolution as the smaller monitor.
Can't say for sure why, but based on my experience, it should be a surmountable problem. Possibly HDCP is affecting behavior, or the HDMI cable. Have you tried any other cables? Cheaper HDMI cables are often a cause of otherwise inexplicable trouble.
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen.
What's likely to be happening here is that the TV does not support the lower 1600x900 mode that Xorg automatically uses without being told otherwise for the larger resolution screen, so both falls back to a lower mode, and displays that mode without stretching, confining to the pixels on the 1920x1080 screen matching the actual mode used. If there is a video mode dictated on the kernel's cmdline (from bootloader), Xorg could be using it, as the Intel driver will do so unless told by xrandr or xorg.conf* to do otherwise.
It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
IME, black/blank space is always at either bottom or right, but only in a screenshot, not on the screen output.
Sounds like neither display is being run in native mode. What is output from 'cat /proc/cmdline'? The whole of /var/log/Xorg.0.log may provide additional useful info.
Is it possible to create a display resolution larger than 1600x900 for the large monitor and properly centred on the screen, possibly using the ‘Monitor and Display’ feature of the TDE Control Centre?
Using TDE controls I've never tried. I always trust Xorg configuration to get screens the way I want them. Here are two such ways:
Over/Under: http://fm.no-ip.com/SS/KDE/tdeDesktop-1920x2130x120viaXrandr-iHaswell.jpg
Side by side: http://fm.no-ip.com/SS/KDE/tdeDesktop-3600x1080x120viaXorgdotconf-iHaswell.j...
In the over/under you can see the xrandr command responsible in the Konsole windows (and from whence it came, a personal creation). For the side by side I used this xorg.conf instead of xrandr: http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1680x1050left-digi1920x10...
Of course the disparity between my screen sizes and yours are smaller, but they do have different native resolutions, and principles in controlling them are the same.
Note that in both my configurations I have forced logical DPI to a value that suits my needs. Via xrandr there are two ways to do this, --dpi and --fbmm. In xorg.conf, DisplaySize controls it. You can pick one that best suits your environment and display size disparity. If you don't, DPI will be forced to 96 on the lower resolution screen, and fall where happenstance puts it on the larger. Here's a file with examples, saving the trouble of calculating sizes to achieve many DPI possibilities: http://fm.no-ip.com/Share/Linux/DisplaySize
This is the web URL shown in the Firefox and SeaMonkey windows: http://fm.no-ip.com/Auth/dpi-screen-window.html
This is the script responsible for the output shown in the Konsole windows: http://fm.no-ip.com/Share/Linux/xfetch.sh
Hope this helps!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-12-23 14:18, Felix Miata wrote:
Ken Heard composed on 2015-12-22 15:22 (UTC+0700):
I have a box with Debian Wheezy and TDE installed in it.
So do I. :-)
This is its motherboard: http://us.msi.com/product/motherboard/B85-G41-PC-Mate.html
What's yours? At least, tell which chipset and video you have via lspci output.
This is my parentboard: http://www.gigabyte.com/products/product-page.aspx?pid=4600#ov
The chipset is the Intel Z87 which is the same as the H87, except the Z87 is designed for overclocking whhich I do not use.
Output of lspci: 00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Haswell Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host Controller (rev 05) 00:16.0 Communication controller: Intel Corporation Lynx Point MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 05) 00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation Lynx Point High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #1 (rev d5) 00:1c.3 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #4 (rev d5) 00:1c.4 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #5 (rev d5) 00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA Controller 1 [AHCI mode] (rev 05) 00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 05) 02:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit Ethernet (rev 10) 03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)
Note that there are two audio controllers and two ethernet controllers. I am not sure which auto controller is used --or whether it matters -- but I have to use the Atheros ethernet controller because the Intel one does not work.
The GPU has three connectors, one DVI and two HDMI.
Mine has one each of VGA, DVI and HDMI.
Mine has one DVI and two HDMI.
I have two monitors connected to it.
Again do I. :-)
The diagonal measurement of one is 49 cm. It has a 1600x900 resolution and is connected to the box by a DVI cable.
Diagonal of my 1680x1050 connected via VGA cable is 56cm.
The other is a TV/monitor with a diagonal measurement of 124 cm (49 inches). It is connected to the box by HDMI.
The resolution of this monitor is 1920x1080 (FHD), the same as yours although my screen diagonal is 7 cm shorter than yours..
Diagonal of my 1920x1080 connected by DVI to PC and HDMI to TV is 80cm.
The box recognizes its existence, but the display on it has the same resolution as the smaller monitor.
Can't say for sure why, but based on my experience, it should be a surmountable problem. Possibly HDCP is affecting behavior, or the HDMI cable. Have you tried any other cables? Cheaper HDMI cables are often a cause of otherwise inexplicable trouble.
It is a 1.4a HDMI cable 10 m long.
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen.
What's likely to be happening here is that the TV does not support the lower 1600x900 mode that Xorg automatically uses without being told otherwise for the larger resolution screen, so both falls back to a lower mode, and displays that mode without stretching, confining to the pixels on the 1920x1080 screen matching the actual mode used. If there is a video mode dictated on the kernel's cmdline (from bootloader), Xorg could be using it, as the Intel driver will do so unless told by xrandr or xorg.conf* to do otherwise.
I don't know where to find the cmdline; I have never used xrandr; and there is no xorg.conf anywhere in my box.
It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
IME, black/blank space is always at either bottom or right, but only in a screenshot, not on the screen output.
Sounds like neither display is being run in native mode. What is output from 'cat /proc/cmdline'? The whole of /var/log/Xorg.0.log may provide additional useful info.
cat /proc/cmdline returns the following: BOOT_IMAGE=/vmlinuz-3.16.0-0.bpo.4-amd64 root=UUID=056f8d50-7958-4655-bfa6-39b5d03f0b03 ro quiet
What seems to me to be relevant in /var/log/Xorg.0.log follows. [ 57.306] X Protocol Version 11, Revision 0 [ 57.306] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [ 57.306] Current Operating System: Linux TH 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6~bpo70+1 (2015-11-11) x86_64 [ 57.306] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-0.bpo.4-amd64 root=UUID=056f8d50-7958-4655-bfa6-39b5d03f0b03 ro quiet [ 57.306] Build Date: 09 February 2015 09:46:52AM [ 57.306] xorg-server 2:1.12.4-6+deb7u6 (Julien Cristau jcristau@debian.org) [ 57.306] Current version of pixman: 0.26.0 [ 57.306] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 57.306] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 57.306] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec 23 07:58:00 2015 [ 57.318] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 57.398] (==) No Layout section. Using the first Screen section. [ 57.398] (==) No screen section available. Using defaults. [ 57.398] (**) |-->Screen "Default Screen Section" (0) [ 57.398] (**) | |-->Monitor "<default monitor>" [ 57.398] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration.
Is it possible to create a display resolution larger than 1600x900 for the large monitor and properly centred on the screen, possibly using the ‘Monitor and Display’ feature of the TDE Control Centre
The rest of your post is so far beyond my experience and will require more study on my part of the URLs on your website. I do not have time to do that study tonight or for obvious reasons in the next few days. I may have questions to ask later.
In any event, thank you for all the information herein. I have learned a lot already, but obviously I have more to learn. I feel that it is only a matter of time before I solve the problem I described in my original post.
Ken - ------------------------------------------------------------------
Using TDE controls I've never tried. I always trust Xorg configuration to get screens the way I want them. Here are two such ways:
Over/Under: http://fm.no-ip.com/SS/KDE/tdeDesktop-1920x2130x120viaXrandr-iHaswell.jpg
Side by side: http://fm.no-ip.com/SS/KDE/tdeDesktop-3600x1080x120viaXorgdotconf-iHaswell.j...
In the over/under you can see the xrandr command responsible in the Konsole windows (and from whence it came, a personal creation). For the side by side I used this xorg.conf instead of xrandr: http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1680x1050left-digi1920x10...
Of course the disparity between my screen sizes and yours are smaller, but they do have different native resolutions, and principles in controlling them are the same.
Note that in both my configurations I have forced logical DPI to a value that suits my needs. Via xrandr there are two ways to do this, --dpi and --fbmm. In xorg.conf, DisplaySize controls it. You can pick one that best suits your environment and display size disparity. If you don't, DPI will be forced to 96 on the lower resolution screen, and fall where happenstance puts it on the larger. Here's a file with examples, saving the trouble of calculating sizes to achieve many DPI possibilities: http://fm.no-ip.com/Share/Linux/DisplaySize
This is the web URL shown in the Firefox and SeaMonkey windows: http://fm.no-ip.com/Auth/dpi-screen-window.html
This is the script responsible for the output shown in the Konsole windows: http://fm.no-ip.com/Share/Linux/xfetch.sh
Hope this helps!
Ken Heard composed on 2015-12-23 22:44 (UTC+0700):
Felix Miata wrote:
Ken Heard composed on 2015-12-22 15:22 (UTC+0700):
I have a box with Debian Wheezy and TDE installed in it.
This is my parentboard: http://www.gigabyte.com/products/product-page.aspx?pid=4600#ov
Output of lspci: 00:02.0 VGA compatible controller: Intel Corporation Haswell Integrated Graphics Controller (rev 06)
Mine reads slightly differently, but I doubt there's any functional difference: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Can't say for sure why, but based on my experience, it should be a surmountable problem. Possibly HDCP is affecting behavior, or the HDMI cable. Have you tried any other cables? Cheaper HDMI cables are often a cause of otherwise inexplicable trouble.
It is a 1.4a HDMI cable 10 m long.
This is potentially an obstacle. Do a little research to understand: https://www.google.com/search?q=hdmi+cable+length
What's likely to be happening here is that the TV does not support the lower 1600x900 mode that Xorg automatically uses without being told otherwise for the larger resolution screen, so both falls back to a lower mode, and displays that mode without stretching, confining to the pixels on the 1920x1080 screen matching the actual mode used. If there is a video mode dictated on the kernel's cmdline (from bootloader), Xorg could be using it, as the Intel driver will do so unless told by xrandr or xorg.conf* to do otherwise.
I have never used xrandr; and
Needing it is a bit of a nuisance. Most people with single displays will never need it. Often it's the only way as a practical matter a multiple display user can achieve desired results. Use the URL I previously provided (...setup) as a guide to some possibilities. Only any single line in it should ever be used, but having them all as comments facilitates quick switching among possibilities in whilst testing by simply uncommenting any single line desired.
there is no xorg.conf anywhere in my box.
Most people never need them. Automagic made them optional, typically for overriding unwanted automagic. Any who need one as an alternative to xrandr must create it. Some DEs have built-in tools that either create one, or operated as an alternative to one. AFAICT, TDE is not one of them. NVidia users using proprietary drivers get a tool to create one automatically. Intel and other FOSS driver users must either create one manually, or copy one from somewhere, into /etc/X11/.
Various URLs that may help in constructing your own xorg.conf*: https://01.org/linuxgraphics/documentation/how-set-dual-head-intel-graphics-... https://wiki.gentoo.org/wiki/Xorg.conf https://wiki.gentoo.org/wiki/Xorg/Multihead http://www.thinkwiki.org/wiki/Xorg_RandR_1.2 https://wiki.archlinux.org/index.php/Multihead
cat /proc/cmdline returns the following: BOOT_IMAGE=/vmlinuz-3.16.0-0.bpo.4-amd64 root=UUID=056f8d50-7958-4655-bfa6-39b5d03f0b03 ro quiet
OK, so cmdline is providing no interference with Xorg operation. If you want a more informative boot process you can remove "quiet" from /etc/default/grub. Then on next boot reconfig (e.g. new kernel), it will be removed from grub.cfg, changing the look of your boot process.
What seems to me to be relevant in /var/log/Xorg.0.log follows. [ 57.306] Current Operating System: Linux TH 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6~bpo70+1 (2015-11-11) x86_64
This is equivalent to running 'uname -a'.
[ 57.306] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-0.bpo.4-amd64 root=UUID=056f8d50-7958-4655-bfa6-39b5d03f0b03 ro quiet
You said you couldn't find it, but here it is. :-)
[ 57.318] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 57.398] (==) No Layout section. Using the first Screen section. [ 57.398] (==) No screen section available. Using defaults. [ 57.398] (**) |-->Screen "Default Screen Section" (0) [ 57.398] (**) | |-->Monitor "<default monitor>" [ 57.398] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration.
All this is simply informing it's operating via automagic rather than having found an xorg.conf. More relevant is the output you'll see if you run the script I pointed you to, in particular, lines containing "Output", "connected" and/or "using initial mode". They tell you the output names of your video connectors that are required to design working xrandr commands or xorg.conf elements.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/22/2015 09:22 AM, Ken Heard wrote:
I have a box with Debian Wheezy and TDE installed in it. The GPU has three connectors, one DVI and two HDMI.
I have two monitors connected to it. The diagonal measurement of one is 49 cm. It has a 1600x900 resolution and is connected to the box by a DVI cable.
The other is a TV/monitor with a diagonal measurement of 124 cm (49 inches). It is connected to the box by HDMI. The box recognizes its existence, but the display on it has the same resolution as the smaller monitor.
It consequently uses only about 40-45% of the screen area, nor is it centred on the screen. It starts more or less from the upper left corner and leaves an L shaped unused black space on the bottom and right sides. The left side does not correspond to the left side of the screen; a strip on the left side of the display is seen on the smaller monitor but not on the large one.
Is it possible to create a display resolution larger than 1600x900 for the large monitor and properly centred on the screen, possibly using the ‘Monitor and Display’ feature of the TDE Control Centre?
Regards, Ken
Ken, following up all the emails on this topic, could you file a bug report on bugszilla so we don't forget about it? I also remember some issues some time ago when I used two monitors. Cheers Michele
Michele Calgaro composed on 2015-12-30 20:01 (UTC+0100):
following up all the emails on this topic, could you file a bug report on bugszilla so we don't forget about it? I also remember some issues some time ago when I used two monitors.
IMO it hasn't been made clear that there is any bug, unless it's with lack of clear howto docs anywhere. Was KDE3 ever able to do the configuration of multiple displays? I'm not sure even KDE4 ever was able to. This WFM at the Xorg level, but without any laptops I'm not able to precisely duplicate OP's hardware configuration. Before filing, better to be sure through discussion here what the bug is, or maybe move discussion to [trinity-devel].
Felix Miata wrote:
Michele Calgaro composed on 2015-12-30 20:01 (UTC+0100):
following up all the emails on this topic, could you file a bug report on bugszilla so we don't forget about it? I also remember some issues some time ago when I used two monitors.
IMO it hasn't been made clear that there is any bug, unless it's with lack of clear howto docs anywhere. Was KDE3 ever able to do the configuration of multiple displays? I'm not sure even KDE4 ever was able to. This WFM at the Xorg level, but without any laptops I'm not able to precisely duplicate OP's hardware configuration. Before filing, better to be sure through discussion here what the bug is, or maybe move discussion to [trinity-devel].
KDE3 or KDE4 are able to do as much as xrandr can do. All boils down to the chipset, the driver and the display.
It took my couple of hours to configure mine (attached). Perhaps it could give you some ideas. I also added/quoted some of the sources.
Also you or OP mentioned having wheezy. I mentioned I had to upgrade to jessie. In my opinion for wheezy you have to check which Xorg version and intel(i915) driver version you have installed.
I replaced in the beginning of this year Dell d520 with e5440 and found out it could not run with the Xorg version and intel driver included in wheezy.
I then had to find out that it is not possible to have both built in and external displays with their native resolutions working. Unfortunately although officially Dell was offering this model with nv chipset they were not able to deliver. I think with the nv it would consume more power, cost more but would have had better support.
Xorg suggests you try the latest version of their driver and if you can confirm the problem - log a bug.
Perhaps Ken (OP) can test with ubuntu live cdrom or usb stick and report back if something is different.
deloptes composed on 2015-12-30 23:55 (UTC+0100):
Felix Miata wrote:
IMO it hasn't been made clear that there is any bug, unless it's with lack of clear howto docs anywhere. Was KDE3 ever able to do the configuration of multiple displays? I'm not sure even KDE4 ever was able to. This WFM at the Xorg level, but without any laptops I'm not able to precisely duplicate OP's hardware configuration. Before filing, better to be sure through discussion here what the bug is, or maybe move discussion to [trinity-devel].
KDE3 or KDE4 are able to do as much as xrandr can do. All boils down to the chipset, the driver and the display.
To be clear, my meaning WRT KDE3 & up was configuring, not utilizing what has been pre-configured via xrandr startup script or xorg.conf*.
It took my couple of hours to configure mine (attached). Perhaps it could give you some ideas.
Section "Files"
... Irrelevant to the subject. IME, automagic fully handles this in every case, while manual inclusion provides opportunity to miss some obscurely installed fonts.
Section "Module"
... Usually not relevant to configuring display configuration.
Section "InputDevice" Section "InputDevice" Section "InputDevice"
... Irrelevant to the subject. IME, automagic generally handles these satisfactorily.
Section "Monitor" Identifier "eDP1" Section "Monitor" Identifier "DP2"
... Relevant.
Modeline "1920x1080@60.0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
... Modelines are nearly always handled automagically as well as , so I repeat: I've NEVER EVER needed to put any modeline in any distro's xorg.conf, and I do a LOT of testing with different distro versions, Xorg versions, CRT and LCD displays, gfxchips and video drivers. Xorg calculates the modelines it needs if it has any valid data about the hardware. Usually EDID is sufficient. When not (e.g. invalid EDID), all it needs is the display's HorizSync and VertRefresh ranges, and the desired resolution.
I every case, providing Xorg with HorizSync and VertRefresh ranges, and desired resolution (PreferredMode in server versions since it was created; previously, and currently with non-KMS drivers via 'Subsection "Display"'s 'Modes'), provided all that was needed.
Again, Xorg's built in modeline calculator works as well as gtf or cvt, and does so automatically, so manual modeline generation should be an absolute last resort only when all else fails. Manual calculation is an absolute and complete waste of time otherwise.
IOW, don't waste your time on modelines unless you like wasting more time on an already tedious task, or you've tried absolutely everything else, without success. And don't bloat an already confusing subject by suggesting to an OP otherwise.
Section "Monitor"
... Relevant.
Modeline "1920x1080@60.0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
... Irrelevant
Section "Monitor"
... Relevant.
Modeline "1920x1080@60.0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
...
No.
Section "Monitor" Identifier "HDMI1"
... Relevant.
Section "Monitor" Identifier "HDMI2"
Relevant.
Section "Device" # http://wiki.ubuntuusers.de/Grafikkarten/Intel ### Available Driver options are:- ### Values: <i>: integer, <f>: float, <bool>: "True"/"False", ### <string>: "String", <freq>: "<f> Hz/kHz/MHz", ### <percent>: "<f>%" ### [arg]: arg optional #Option "NoAccel" # [<bool>] #Option "AccelMethod" # <str> Option "AccelMethod" "uxa" #Option "Backlight" # <str> Option "DRI" "on" # <str> #Option "ColorKey" # <i> #Option "VideoKey" # <i> #Option "Tiling" # [<bool>] #Option "LinearFramebuffer" # [<bool>] #Option "SwapbuffersWait" # [<bool>] #Option "TripleBuffer" # [<bool>] #Option "XvPreferOverlay" # [<bool>] Option "HotPlug" "on" # [<bool>] Option "ReprobeOutputs" "on" # [<bool>] #Option "XvMC" # [<bool>] #Option "ZaphodHeads" # <str> #Option "TearFree" # [<bool>] #Option "PerCrtcPixmaps" # [<bool>] #Option "FallbackDebug" # [<bool>] #Option "DebugFlushBatches" # [<bool>] #Option "DebugFlushCaches" # [<bool>] #Option "DebugWait" # [<bool>] #Option "BufferCache" # [<bool>] Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Most options, and BusID, and usually even driver (some driver versions have been a bit broken), are irrelevant WRT configuring resolution and position. The section is necessary, but quite often with nothing more than identifier. The rest is usually no more than obfuscation and opportunity for typos.
Section "ServerFlags"
More handled adquately via automagic.
Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor-eDP1" Monitor "Monitor-DP2" #RightOf "Monitor-eDP1"
More than the above in this section is usually nothing but obfuscation confusing the path to success. Xorg is smart enough to handle the rest automagically.
Section "Screen" Identifier "Screen1" Device "Card0" Monitor "Monitor1"
Ditto.
Section "DRI" Mode 0666 EndSection
That's the default, so also handled via automagic.
Hi it seems you know this stuff pretty well.
Perhaps you can help me use both displays (the built in and the external) in their native resolution
eDP1 connected (normal left inverted right x axis y axis) 1366x768 60.00 + 40.00 DP2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00*+
To be clear, my meaning WRT KDE3 & up was configuring, not utilizing what has been pre-configured via xrandr startup script or xorg.conf*.
It has resize and rotate: /opt/trinity/bin/tderandrtray which is based on libtderandr.so.0 ... and libXrandr.so.2
but again in the stock debian jessie the xorg is not the latest version - I'm using kernel 4.3.3 but still not that good (you just need to see what is in the changelog in past kernels).
You are in favor of automagic, but I never got this intel chipsets automagically work with two displays - no idea why - if it is working for you, you are among the lucky once - please share.
Why I had to put some of the options there I still remember. I just do not remember what is good for what. Thank you for all the comments. Perhaps it will help me recall the details. Perhaps some of them are really not needed, but "never touch a running system" - you know!
The problem I had except the one above, was (as usual) not working external display. Well in wheezy even the LCD was not working. After I upgraded and got it working with the built in, the problem was when unplug the display and plugin for example a beamer - X crashed etc. Very bad when you have to do a presentation infront of people. But good old D. tests all this in advance, so at least I knew what I should fix.
Any ideas are really appreciated.
Ohm and I forgot I use this via docking station usually - but I do not think it is relevant. The problems I mentioned were observed when using it without docking station.
I urge again Ken to get latest ubuntu live and test and report back if he had more luck.
thanks again
deloptes composed on 2015-12-310 02:26 (UTC+0100):
Perhaps you can help me use both displays (the built in and the external) in their native resolution
http://fm.no-ip.com/SS/KDE/desktopR14-3520x1200x120-jessie-intel.jpg should show you what's possible via xorg.conf in stock Jessie and R14 on Intel.
eDP1 connected (normal left inverted right x axis y axis) 1366x768 60.00 + 40.00 DP2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00*+
For your xorg.conf, start with: http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1600x1200left-digi1920x10...
Change monitor-VGA1 to monitor-eDP1 Change 1600x1200 to 1366x768 Change monitor-HDMI1 to monitor-DP2
Adjust DisplaySize line as desired, or comment or delete. IIRC, only one can be applied, so when using both large and much smaller displays, some happy medium will need to be selected to prevent one from being too teensy or the other too gigantic.
If you want over/under instead of left/right, start instead with: http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1600x1200under-digi1600x1...
Delete the comment lines if you care.
but again in the stock debian jessie the xorg is not the latest version - I'm using kernel 4.3.3 but still not that good (you just need to see what is in the changelog in past kernels).
AFAICT, what you want has been functional since long before wheezy.
You are in favor of automagic, but I never got this intel chipsets automagically work with two displays - no idea why - if it is working for you, you are among the lucky once - please share.
For some things automagic is perfect. For others, it's just not up to task. With multiple displays, there's no way for it to guess what you want. It needs some kind of seeding, if not fully spelled out, to go on.
The problem I had except the one above, was (as usual) not working external display. Well in wheezy even the LCD was not working. After I upgraded and got it working with the built in, the problem was when unplug the display and plugin for example a beamer - X crashed etc. Very bad when you have to do a presentation infront of people. But good old D. tests all this in advance, so at least I knew what I should fix.
Again, there's nothing I can do specific to laptops or docking stations. I have lots of hardware to test with, but all "desktops".
Felix Miata composed on 2015-12-31 21:59 (UTC-0500):
deloptes composed on 2015-12-310 02:26 (UTC+0100):
Perhaps you can help me use both displays (the built in and the external) in their native resolution
http://fm.no-ip.com/SS/KDE/desktopR14-3520x1200x120-jessie-intel.jpg should show you what's possible via xorg.conf in stock Jessie and R14 on Intel.
eDP1 connected (normal left inverted right x axis y axis) 1366x768 60.00 + 40.00 DP2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00*+
For your xorg.conf, start with: http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1600x1200left-digi1920x10...
Change monitor-VGA1 to monitor-eDP1 Change 1600x1200 to 1366x768 Change monitor-HDMI1 to monitor-DP2
Adjust DisplaySize line as desired, or comment or delete. IIRC, only one can be applied, so when using both large and much smaller displays, some happy medium will need to be selected to prevent one from being too teensy or the other too gigantic.
I neglected to point out, the template's HorizSync and VertRefresh lines need to be either removed or conformed to the specifications of your attached displays. EDID should provide that info, so they shouldn't be needed, leaving it up to automagic.
If you want over/under instead of left/right, start instead with: http://fm.no-ip.com/Share/Linux/xorg.conf-intel-vga1600x1200under-digi1600x1...
Delete the comment lines if you care.
but again in the stock debian jessie the xorg is not the latest version - I'm using kernel 4.3.3 but still not that good (you just need to see what is in the changelog in past kernels).
AFAICT, what you want has been functional since long before wheezy.
You are in favor of automagic, but I never got this intel chipsets automagically work with two displays - no idea why - if it is working for you, you are among the lucky once - please share.
For some things automagic is perfect. For others, it's just not up to task. With multiple displays, there's no way for it to guess what you want. It needs some kind of seeding, if not fully spelled out, to go on.
The problem I had except the one above, was (as usual) not working external display. Well in wheezy even the LCD was not working. After I upgraded and got it working with the built in, the problem was when unplug the display and plugin for example a beamer - X crashed etc. Very bad when you have to do a presentation infront of people. But good old D. tests all this in advance, so at least I knew what I should fix.
Again, there's nothing I can do specific to laptops or docking stations. I have lots of hardware to test with, but all "desktops".
Hi Felix,
thank you for the effort and Happy New Year
Again, there's nothing I can do specific to laptops or docking stations. I have lots of hardware to test with, but all "desktops".
I do not pretend to be an expert, but from what I see (when you specify Screen 1/2 etc) you have real dual head video adapter. Thus this gives you the ability to control the different resolution on each screen.
I'll give it a try anyway, just to "have tried it", but I do not think it will help me get what I want. I recall I spent a lot of time, just finding out at the end that it is not possible.
Thanks again
regards
Felix,
I tried this and that without success. Honestly the intel hardware seems to be such cheep junk, that I feel sorry paying for that.
I know I wanted to try the latest intel driver version, but never got the time and courage.
example
[ 5742.226836] [drm] stuck on render ring [ 5742.227813] [drm] GPU HANG: ecode 7:0:0x84dfbffe, in cubestorm [6959], reason: Ring hung, action: reset [ 5742.227815] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 5742.227815] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 5742.227816] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 5742.227817] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 5742.227818] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 5742.229795] drm/i915: Resetting chip after gpu hang [ 5748.233555] [drm] stuck on render ring [ 5748.235408] [drm] GPU HANG: ecode 7:0:0x85dffff8, in cubestorm [6959], reason: Ring hung, action: reset [ 5748.237493] drm/i915: Resetting chip after gpu hang [22090.064813] perf interrupt took too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 [29978.586965] usb 1-4.2.2: 3:1: cannot get freq at ep 0x84 [29978.609045] usb 1-4.2.2: 3:1: cannot get freq at ep 0x84 [87206.810427] pci_bus 0000:01: Allocating resources [87206.810445] pcieport 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 01] add_size 1000 [87206.810449] pcieport 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000 [87206.810455] pci_bus 0000:02: Allocating resources [87206.810516] pcieport 0000:00:1c.3: bridge window [io 0x1000-0x0fff] to [bus 02] add_size 1000 [87206.810518] pcieport 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02] add_size 200000 add_align 100000 [87206.810523] pci_bus 0000:03: Allocating resources [87206.810531] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.810536] pcieport 0000:00:1c.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000 [87206.810538] pcieport 0000:00:1c.0: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000 [87206.810540] pcieport 0000:00:1c.3: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000 [87206.810542] pcieport 0000:00:1c.3: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000 [87206.810543] pcieport 0000:00:1c.0: res[13]=[io 0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000 [87206.810545] pcieport 0000:00:1c.0: res[13]=[io 0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000 [87206.810546] pcieport 0000:00:1c.3: res[13]=[io 0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000 [87206.810547] pcieport 0000:00:1c.3: res[13]=[io 0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000 [87206.810556] pcieport 0000:00:1c.0: BAR 15: assigned [mem 0xdf200000-0xdf3fffff 64bit pref] [87206.810560] pcieport 0000:00:1c.3: BAR 15: assigned [mem 0xdf400000-0xdf5fffff 64bit pref] [87206.810564] pcieport 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] [87206.810566] pcieport 0000:00:1c.3: BAR 13: assigned [io 0x3000-0x3fff] [87206.811506] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.811526] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.811574] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.811847] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.811861] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.811893] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87206.811963] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [87288.184845] glknots[4995]: segfault at 208 ip 00007f530d81cd2d sp 00007ffd6c4e0080 error 4 in i965_dri.so[7f530d4c9000+51e000]
deloptes composed on 2016-01-01 22:49 (UTC+0100):
I tried this and that without success. Honestly the intel hardware seems to be such cheep junk, that I feel sorry paying for that.
Given Haswell is >2 years old, it ought to work for everybody using it with any distro as new as Jessie...
I know I wanted to try the latest intel driver version, but never got the time and courage.
example
[ 5742.226836] [drm] stuck on render ring [ 5742.227813] [drm] GPU HANG: ecode 7:0:0x84dfbffe, in cubestorm [6959], reason: Ring hung, action: reset [ 5742.227815] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 5742.227815] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
Obviously some kind of incompatibility between your hardware and the software exists. Before giving up, or as suggested, filing a freedesktop DRI/DRM bug, I suggest bringing your problem to http://lists.freedesktop.org/mailman/listinfo/intel-gfx to see if it's a known problem or one already solved in software you've not tried. Maybe ULT is the problem rather than a more general Intel problem. Another possibility is what you have is a warranty problem.
Felix Miata wrote:
Obviously some kind of incompatibility between your hardware and the software exists. Before giving up, or as suggested, filing a freedesktop DRI/DRM bug, I suggest bringing your problem to http://lists.freedesktop.org/mailman/listinfo/intel-gfx to see if it's a known problem or one already solved in software you've not tried. Maybe ULT is the problem rather than a more general Intel problem. Another possibility is what you have is a warranty problem.
Thanks, yes the problem is the eDP1 display's native resolution 1366x768 - it does not match anything that the external one supports (which is standard full HD 1920x1080).
I've been already @intel-gfx and they suggest trying their latest driver ... which I did not have the time and will to do.
I finally do not care as far as I can use one of them, but still our starting point was about compatibility etc.
I think also Dell is somehow responsible for buying the lowest quality at the end .... but no one can blame them as well - they offer alternative NV instead Intel, only that it is not available and must be ordered extra ... which somehow reminds me of the intel/ibm/MS story from the late 80ies.
Any way - thanks a lot for the useful information and kind regards
deloptes composed on 2016-01-02 00:11 (UTC+0100):
Thanks, yes the problem is the eDP1 display's native resolution 1366x768 - it does not match anything that the external one supports (which is standard full HD 1920x1080).
What makes you think that?
I've been already @intel-gfx and they suggest trying their latest driver ... which I did not have the time and will to do.
Maybe a live DVD would be worth trying. Best live DVD anywhere, granddaddy of live media, the only live media I ever use (if you don't count installation media as live media), is a Debian: http://knoppix.net/
Its 7.6 has kernel 4.2.2 and server 17.3, both newer than jessie.
I finally do not care as far as I can use one of them, but still our starting point was about compatibility etc.
I think also Dell is somehow responsible for buying the lowest quality at the end .... but no one can blame them as well - they offer alternative NV instead Intel, only that it is not available and must be ordered extra ... which somehow reminds me of the intel/ibm/MS story from the late 80ies.
I don't think this is about Dell quality. It's just another big marketing company, so it has to compete by matching the low industry standard 1366x768 generally. I doubt Dell is responsible for the existence of 1366x768, which is an unfortunate lowfi resolution that didn't deserve to ever have been created.
Have you tried running both at 1280x720, just to see if that standard HDTV 720p resolution is possible on your displays? It works on my Vizio 1920x1080 and my Lenovo 1680x1050 even though not listed in specs or EDID output.
Felix Miata wrote:
What makes you think that?
If you compare the resolution from the first and the second.
Meanwhile (and big thanks to you that you forced me digging into it) I found what I needed.
First of all the xorg.conf is not that bad - it provides to the X server exactly what I need. Perhaps modlines and some other stuff can be skipped - agreed. Back then when I bought the notebook (it is like 1y ago) I did not have that much time to dig into that, because of too many reasons.
However now I checked again xrandr and found out the scale-from option
So for example xrandr --output eDP1 --scale-from 1920x1080 does exactly what I was missing.
Now I need to find out how I can use the two monitors independent of each other. I mean when I expand a window it should expand into the range of the current monitor, the window is in. I'm sure I've had this before.
regards
deloptes composed on 2016-01-02 02:46 (UTC+0100):
Felix Miata wrote:
deloptes composed on 2016-01-02 00:11 (UTC+0100):
Thanks, yes the problem is the eDP1 display's native resolution 1366x768 - it does not match anything that the external one supports (which is standard full HD 1920x1080).
What makes you think that?
If you compare the resolution from the first and the second.
That one won't support what the other does doesn't matter. Every supported mode on one can be absent from the other, and yet both can work at once. It's *expected* that displays with different native modes can each be used at their native mode, and it follows that supported modes can be selected abitrarily and independently. So, I can't imagine how you arrived at that conclusion.
Meanwhile (and big thanks to you that you forced me digging into it) I found what I needed.
:-)
First of all the xorg.conf is not that bad - it provides to the X server exactly what I need. Perhaps modlines and some other stuff can be skipped - agreed. Back then when I bought the notebook (it is like 1y ago) I did not have that much time to dig into that, because of too many reasons.
However now I checked again xrandr and found out the scale-from option
So for example xrandr --output eDP1 --scale-from 1920x1080 does exactly what I was missing.
:-D Hopefully when you get there you won't be blocked by errors like those shared in your 2016-01-01 22:49 (UTC+0100) thread post. :-p
Now I need to find out how I can use the two monitors independent of each other. I mean when I expand a window it should expand into the range of the current monitor, the window is in. I'm sure I've had this before.
That seems to describe what you're looking at in http://fm.no-ip.com/SS/KDE/desktopR14-3520x1200x120-jessie-intel.jpg
deloptes composed on 2016-01-02 00:11 (UTC+0100):
Thanks, yes the problem is the eDP1 display's native resolution 1366x768 - it does not match anything that the external one supports (which is standard full HD 1920x1080).
What makes you think that?
I've been already @intel-gfx and they suggest trying their latest driver ... which I did not have the time and will to do.
Maybe a live DVD would be worth trying. Best live DVD anywhere, granddaddy of live media, the only live media I ever use (if you don't count installation media as live media), is a Debian: http://knoppix.net/
Its 7.6 has kernel 4.2.2 and server 17.3, both newer than jessie.
I finally do not care as far as I can use one of them, but still our starting point was about compatibility etc.
I think also Dell is somehow responsible for buying the lowest quality at the end .... but no one can blame them as well - they offer alternative NV instead Intel, only that it is not available and must be ordered extra ... which somehow reminds me of the intel/ibm/MS story from the late 80ies.
I don't think this is about Dell quality. It's just another big marketing company, so it has to compete by matching the low industry standard 1366x768 generally. I doubt Dell is responsible for the existence of 1366x768, which is an unfortunate lowfi resolution that didn't deserve to ever have been created.
Have you tried running both at 1280x720, just to see if that standard HDTV 720p resolution is possible on your displays? It works on my Vizio 1920x1080 and my Lenovo 1680x1050 even though not listed in specs or EDID output.
Felix Miata wrote:
I don't think this is about Dell quality. It's just another big marketing company, so it has to compete by matching the low industry standard 1366x768 generally. I doubt Dell is responsible for the existence of 1366x768, which is an unfortunate lowfi resolution that didn't deserve to ever have been created.
I am pretty glad with Dell. The last one I used is still working already 10y old.
The problem is not Dell but Intel and the poisoned market practice ... because of competition. Intel bundles and were sued for that. Dell has not much choice.
Have you tried running both at 1280x720, just to see if that standard HDTV 720p resolution is possible on your displays? It works on my Vizio 1920x1080 and my Lenovo 1680x1050 even though not listed in specs or EDID output.
No man, I'm working father ... and honestly if I had the time I would use it for something more meaningful ... but today it is an exception.
If I only could find a way to tell X that I want the panel to not expand to the other screen but to stay on the primary one only ... and the windows to expand only to the one they are placed on. I'm sure I had this with the old Dell (intel card).
regards and thanks for inspiration
deloptes composed on 2016-01-02 03:39 (UTC+0100):
I am pretty glad with Dell. The last one I used is still working already 10y old.
My newest Dell is >5 years old. My oldest that I know still works is about 16. I have a whole bunch in between, most working, some waiting for me to replace bad power supply and/or motherboard caps.
If I only could find a way to tell X that I want the panel to not expand to the other screen but to stay on the primary one only ... and the windows to expand only to the one they are placed on. I'm sure I had this with the old Dell (intel card).
Again I don't understand the problem(s). In http://fm.no-ip.com/SS/KDE/desktopR14-3520x1200x120-jessie-intel.jpg the only windows appearing on both screens at once are those I purposely put there. None of the windows you see there will fullscreen into more than one. FF for example will fullscreen to whichever screen the majority of its pixels occupy. Getting it to occupy the whole desktop (in fewest actions) requires dragging window to a corner, then dragging the opposite sides to the edges of the desktop.
Felix Miata wrote:
Again I don't understand the problem(s). In http://fm.no-ip.com/SS/KDE/desktopR14-3520x1200x120-jessie-intel.jpg the only windows appearing on both screens at once are those I purposely put there. None of the windows you see there will fullscreen into more than one. FF for example will fullscreen to whichever screen the majority of its pixels occupy. Getting it to occupy the whole desktop (in fewest actions) requires dragging window to a corner, then dragging the opposite sides to the edges of the desktop.
Yes, for some reason here it expands to both monitors. Perhaps because there is only 1 Screen. Not sure ATM, but will go on tomorrow. It was a good progress
regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/30/2015 08:01 PM, Michele Calgaro wrote:
Ken, following up all the emails on this topic, could you file a bug report on bugszilla so we don't forget about it? I also remember some issues some time ago when I used two monitors. Cheers Michele
I have decided to file bug report 2571 for this. If there is no problem, we will just close the bug after investigation, otherwise we will know a fix is required. Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As the creator of this thread, I appreciate all the advice I have received, especially from Felix Miata. Unfortunately pressure of work has so far prevented me from following up on this particular project. I expect to get back to it sometime this month.
Regards, Ken