xrandr / arandr RRSetScreenSize and RRSetCrtcConfig errors - xorg

I'm trying to get X to use 3 external monitors from my laptop.
TLDR; It works 10% of the time. arandr shows a light gray box that contains the monitors (see image). When the monitors don't all fit, I get errors.
What is the light gray background box called in X's configuration (see image)?
How can I set the size of the light-gray box?
This works 10% of the time:
1x laptop screen eDP1 (1920x1080),
2x external DVI-I-1 and DVI-I-2 (1920x1080) via this USB3 device
1x external HDMI1 (1680x900)
Here's the script arandr built (added linebreaks for readibility).
#!/bin/sh
xrandr --output VIRTUAL1 --off
--output eDP1 --primary --mode 1920x1080 --pos 0x1080 --rotate normal
--output HDMI1 --mode 1600x900 --pos 1920x1080 --rotate normal
--output VGA1 --off --output DVI-I-1 --mode 1920x1080 --pos 1920x0 --rotate normal
--output DVI-I-2 --mode 1920x1080 --pos 0x0 --rotate normal
The issue seems to be the HDMI monitor and it's odd resolution 1600x900. When x tries to auto-configure it, it makes the width 1920+1600 instead of 1920+1920. See image below.
The script gives errors
if the HDMI isn't plugged in:
xrandr: cannot find mode 1600x900
if the HDMI is plugged in, but DVI-I-1 is outside the light gray background box
XRandR failed:
XRandR returned error code 1: X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x780
Serial number of failed request: 53
Current serial number in output stream: 53
or the error in the image below (most common)
This works once in awhile, and either the laptop magically configures when everything's plugged in, or
the USB or HDMI monitors don't work or
the screen buffers get corrupted and I have to ctrl-alt-backspace or
random effect roll a d20 (mirroring, etc).
arandr looks like below (note how DVI-I-1 is outside the light gray background). After screwing around with it alot:
It NEVER works when the light gray background doesn't fit the monitors.
It ALWAYS works when the light gray background fits the montiors.
It SOMETIMES works when I plug the HDMI monitor in last, but not reliably.
If I run this xrandr (no HDMI), I get an error:
☀ ./3up.sh
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x780
Serial number of failed request: 53
Current serial number in output stream: 53
michael#mc-desktop ~
☔ cat 3up.sh
#!/bin/sh
xrandr --output VIRTUAL1 --off \
--output eDP1 --primary --mode 1920x1080 --pos 0x1080 --rotate normal \
--output VGA1 --off \
--output DVI-I-1 --mode 1920x1080 --pos 1920x0 --rotate normal \
--output DVI-I-2 --mode 1920x1080 --pos 0x0 --rotate normal \
--output HDMI1 --off
I'm using Linux Mint 18 on a System76 Laptop.
Thanks!

I tracked this down to an issue with the intel chip resizing the display improperly.
I upgraded to ubuntu GNOME 16.04 (from Mint 14.04) and it worked. I think it upgraded the intel driver. Anyways, its not perfect, but more stable.

Related

Setting up the EFI Shell in Qemu to allow for Http requests

I am developing an UEFI App that will need to perform a GET request through http.
As a start up point, I want to make sure my setup is working properly so that the http requests can actually go through.
To that end, I spent the last few days trying to make the http command work in the EFI Shell launched inside QEMU.
I can get the ping command to work properly, but calling:
http httpbin.org/get
Always returns: 
Unable to open http protocol on `eth0` - Unsupported
Unable to download the file `/get` on `eth0` - Unsupported
This is my startup.nsh script to configure the EFI Shell's interface:
connect
ifconfig -r eth0
ifconfig -s eth0 dhcp
ifconfig -l eth0
These were my different attempts at invoking Qemu properly:
-netdev user,id=mynet0,hostfwd=tcp::8080-:80 -device e1000,netdev=mynet0 \
        -netdev user,id=user.0 -device e1000,netdev=user.0 \
        -nic user,ipv6=off,model=e1000,mac=52:54:98:76:54:32 \
       
And following this guide I tried to setup a tap, albeit without luck, I'd launch qemu with the following configuration:
-netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no -device e1000,netdev=mynet0,mac=52:55:00:d1:55:01 \
Do you have any clue what step am I missing?
Where do you believe I could be failing in making eth0 supported?
Is the tap crucial?
Are you able to make this setup work on your side?
Update:
Very good suggestion #MiSimon, I hadn't realized that the HttpDxe driver wasn't being built with the OvmfPkg.
I have now added its INF to OvmfPkgX64.dsc and OvmfPkgX64.fdf.
Although, running drivers is displaying a duplicate entry:
0000000A D - - 1 - HttpDxe HttpDxe
0000000A ? - - - - HttpDxe HttpDxe
With respect to calling the http command, the error has progressed to:
Downloading 'http://httpbin.org/get'
Unable to download the file '/get' on 'eth0' - Unsupported
The debug log shows:
HttpNotify: Event - 0, EventStatus - Unsupported
Error: Could not retrieve the host address from DNS server.
The tool requires nearly all network drivers to be loaded.
Make sure your image contains the following drivers:
SnpDxe
MnpDxe
ArpDxe
Ip4Dxe/Ip6Dxe
Dhcp4Dxe/Dhcp6Dxe
Udp4Dxe/Udp6Dxe
DnsDxe
TcpDxe
HttpDxe
HttpUtilitiesDxe
All of them are can be found in EDK2 inside the NetworkPkg.

hcitool starts working and then sputters out

On my Raspberry Pi, I've installed Bluez and I'm running the command:
sudo hcitool lescan
which returns output like this:
4C:0C:F7:63:33:CB (unknown)
8C:85:90:63:A9:29 (unknown)
In the first 5 seconds I get 10+ results. Then it suddenly sputters out -- I barely get 2-3 results every minute!
How can I fix this?

GStreamer/iMX6: streaming h264 encoded video over serial port between iMX6 and PC

Recently, I have started to work on a project that aims at live video streaming applications based on imx6 processors. A quick description of what I have done so far and what I am trying to do:
Setup: imx6 board(Boundary devices Sabre Lite) acting as the video server(using GStreamer imx plugins), and a PC running Ubuntu on it that receives data from imx6 and streams the video using GStreamer features.
On the imx6 processor, I run the 'testvideosrc' and have successfully streamed it using the RTP over UDP using eternet interface between the imx6 and the PC.
Accessing the serial port using the device files in Linux, next I tried out dumping the video data from imx6 board to a serial port and reading this serial port on the PC. For this, the baud rate of both devices was configured to 115200 baud. The encoding 'bitrate' is configured to 5Kbps. Here are the commands:
IMX6:
#gst-launch-1.0 -v videotestsrc pattern=18 ! video/x- raw,width=100,height=50 ! imxvpuenc_h264 bitrate=5 ! h264parse ! filesink location=/dev/ttyUSB1
PC:
#CAPS=video/x-h264
#gst-launch-1.0 -v filesrc location=/dev/ttyUSB1 ! $CAPS ! h264parse ! avdec_h264 ! autovideosink sync=true
There are no errors observed on the imx6 board.
However, I see the following errors at the PC side:
# GST_DEBUG=3 gst-launch-1.0 -v filesrc location=/dev/ttyUSB1 ! $CAPS ! h264parse ! avdec_h264 ! autovideosink sync=true
Setting pipeline to PAUSED …
0:00:00.066439392 15475 0x556d8a01d160 WARN basesrc gstbasesrc.c:3583:gst_base_src_start_complete: pad not activated yet
Pipeline is PREROLLING …
0:00:21.730466251 15475 0x556d8a000940 WARN capsfilter
gstcapsfilter.c:455:gst_capsfilter_prepare_buf: error: Filter caps do not completely specify the output format
0:00:21.730523691 15475 0x556d8a000940 WARN capsfilter gstcapsfilter.c:455:gst_capsfilter_prepare_buf: error: Output caps are unfixed: video/x-h264, width=(int)[ 1, 8192 ], height=(int)[ 1, 8192 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
0:00:21.730676173 15475 0x556d8a000940 WARN basetransform gstbasetransform.c:2159:default_generate_output: could not get buffer from pool: error
0:00:21.730742223 15475 0x556d8a000940 WARN basesrc gstbasesrc.c:3055:gst_base_src_loop: error: Internal data stream error.
0:00:21.730775478 15475 0x556d8a000940 WARN basesrc gstbasesrc.c:3055:gst_base_src_loop: error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstCapsFilter:capsfilter0: Filter caps do not completely specify the output format
Additional debug info:
gstcapsfilter.c(455): gst_capsfilter_prepare_buf (): /GstPipeline:pipeline0/GstCapsFilter:capsfilter0:
Output caps are unfixed: video/x-h264, width=(int)[ 1, 8192 ], height=(int)[ 1, 8192 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
ERROR: pipeline doesn’t want to preroll.
Setting pipeline to NULL …
Freeing pipeline …
Since, the encoding rate is 5Kbps (bitrate=5, as specified in the above command), I suppose it is possible to send this amount of data via the serial port. I realize that currently, the caps negotiation fails, however, I am unsure of how to proceed with this.
On the PC side, reading the serial port with 'cat /dev/ttyUSB1' succeeds with limited data. The data is unreadable(as expected), however it is not a continuous stream.
Does anyone have an idea, on how to solve this. I also think, I am misinterpreting the usage of Linux device files, when I am attempting to read over the serial data file using GStreamer.
My later test, would be to use an actual camera(MIPI) and try streaming it over serial port. Does it seem feasible or is a completely crazy idea to do?
With the following commands, I could get this working on serial with a baud of 19200. However, the latency is very high in the range of 5-6 seconds. With a baud of 1M, it works with less noticeable latency < 1s.
imx6:
gst-launch-1.0 -v videotestsrc pattern=18 ! video/x-raw,width=100,height=50
! imxvpuenc_h264 bitrate=5 ! h264parse ! filesink location=/dev/ttyUSB0
blocksize=1024 max-bitrate=19000 sync=false
PC:
gst-launch-1.0 -v filesrc location=/dev/ttyUSB1 blocksize=1024 ! $CAPS !
h264parse ! avdec_h264 lowres=2 skip-frame=0 ! autovideosink sync=false

Raspberry Pi : use VLC to stream webcam : Logitech C920 [H264 Video without transcoding + Audio + LED control] - SpyCam / BabyCam

I have a RaspberryPi and a Logitech C920 Webcam.
I want to use these devices to work as a surveillance / babycam, i.e. : Stream audio + video over HTTP (or any other protocol) without cpu intensive video
transcoding
The C920 webcam is able to stream H264 natively, so theoretically I won't need to ask RaspberyPi+VLC to transcode the video stream.
The built-in C920 Microphone stream does not seem to be included in the webcam stream.
Cam and microphone are 2 separate devices.
The C920 also has a built-in led indicator. I want to control that to avoid the LED to ligth up while recording.
How can I achieve that ?
This solution is tested and working with versions indicated below.
Using this method, the RaspberryPi3 is always around 5% CPU.
edit 2018-11-18:
One can also see the all-in-one solution prototype on RaspiVWS project homepage (for curious people, see GitHub project)
0. Preliminary checks
1. Webcam video configuration
2. Microphone identification
3. Stream using VLC
4. Make RaspberryPi3+ a Wifi access point
(If you have no existing network to connect your Pi to)
5. Script at startup or as a service
6. [EDIT] Additional commands : infinite loop recording & split video
7. [EDIT] Program execution at a given instant
8. [EDIT] TROUBLESHOOTING
0. Preliminary checks
The answer is working with Raspbian 9.4 Stretch.
Check your version with the following command :
lsb_release -a
You should see:
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
We can rely on the following tools :
v4l allows to control the webcam. It offers the command v4l2-ctl which will allows us to control and config the webcam.
VLC which is not only a video player, but also has powerful streaming capabilities
You can install them with the following commands :
sudo apt-get install vlc
sudo apt-get install v4l-utils
Once everything is installed, you can configure your C920 webcam.
1. Webcam video configuration
v4l2-ctl --all lists all available devices and their config
pi#raspberrypi:~ $ v4l2-ctl --all
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : HD Pro Webcam C920
Bus info : usb-3f980000.usb-1.5
Driver version: 4.14.30
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
Width/Height : 1920/1080
Pixel Format : 'H264'
Field : None
Bytes per Line : 3840
Size Image : 4147200
Colorspace : sRGB
Transfer Function : Default
YCbCr/HSV Encoding: Default
Quantization : Default
Flags :
Crop Capability Video Capture:
Bounds : Left 0, Top 0, Width 1920, Height 1080
Default : Left 0, Top 0, Width 1920, Height 1080
Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1080
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1080
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30/1)
Read buffers : 0
brightness (int) : min=0 max=255 step=1 default=-8193 value=128
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
white_balance_temperature_auto (bool) : default=1 value=1
gain (int) : min=0 max=255 step=1 default=57343 value=255
power_line_frequency (menu) : min=0 max=2 default=2 value=2
white_balance_temperature (int) : min=2000 max=6500 step=1 default=57343 value=4822 flags=inactive
sharpness (int) : min=0 max=255 step=1 default=57343 value=128
backlight_compensation (int) : min=0 max=1 step=1 default=57343 value=0
exposure_auto (menu) : min=0 max=3 default=0 value=3
exposure_absolute (int) : min=3 max=2047 step=1 default=250 value=333 flags=inactive
exposure_auto_priority (bool) : default=0 value=1
pan_absolute (int) : min=-36000 max=36000 step=3600 default=0 value=0
tilt_absolute (int) : min=-36000 max=36000 step=3600 default=0 value=0
focus_absolute (int) : min=0 max=250 step=5 default=8189 value=0 flags=inactive
focus_auto (bool) : default=1 value=1
zoom_absolute (int) : min=100 max=500 step=1 default=57343 value=100
led1_mode (menu) : min=0 max=3 default=3 value=3
led1_frequency (int) : min=0 max=255 step=1 default=0 value=0
The last 2 lines gives us clues to control the built-in LED indicator, for instance, to deactivate the LED indicator.
The -d0 parameter indicates on which device the modifcation should be applied (if you ahve several cams or its device name changed)
v4l2-ctl -d0 --set-ctrl=led1_mode=0
v4l2-ctl -d0 --set-ctrl=led1_frequency=30
2. Microphone identification
The command arecord -l will give us the list of ALSA devices. (ALSA is the audio manager in RaspberryPi)
pi#raspberrypi:~ $ arecord -l
**** Liste des Périphériques Matériels CAPTURE ****
carte 1: C920 [HD Pro Webcam C920], périphérique 0: USB Audio [USB Audio]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0
This means that the built-in microphone is located on hardware 1, periph 0. You can check that in command line with alsamixer -c 1 -V capture
3. Stream using VLC
VLC can be launched using command line.
Since we do not have video and audio already mixed together in a single stream access, we need to ask VLC to do that.
It is the role of the transcoding feature of VLC.
Stream over HTTP
We also want to stream over HTTP, VLC can also achieve that.
cvlc v4l2:///dev/video0:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:standard{access=http,mux=ts,mime=video/ts,dst=:8099}'
Explanation
v4l2:///dev/video0:chroma=h264 gives VLC input data : it grabs the video stream from /dev/video0 and that it is a h264 encoding (if your webcam is the 0th video device, it could also be another number, refer to v4l2-ctl --all command)
:input-slave=alsa://hw:1,0 tells VLC to take another input stream with the video. It is the audio stream identified from the arecord above
--sout tells VLC how to handle the output stream
#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1} tells VLC to convert the audio to mpga codec, 128 kbits/s, 2 channels, 44100 Hz sampling, using all 4 RaspberryPi3+ cores. audiosync is optional. It took me some time to realize this : the webcam h264 video stream is kept as provided (no video transcoding).
:standard{access=http,mux=ts,mime=video/ts,dst=:8099} tells VLC to provide stream over HTTP on port 8099 with the TS muxing format.
On any other device, you can use VLC to access your RaspberryPi3+ VLC stream :
vlc http://<raspberrypi-ip>:8099
It works with any VLC client :
windows
unix
mac
confirmed with iPhone 7 (v11.2.1 (15C153)) with VLC app (3.0.3 (305))
NB : Having the video already in H264 1920x1080 30fps in output of the webcam saves a lot of RaspberryPi3+ CPU.
Different containers
You can also record to various containers, or even containers + stream, here are some examples:
record to MKV
cvlc v4l2:///dev/video0:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:standard{access=file,mux=mkv,dst='/home/pi/Webcam_Record/MyVid.mkv'}'
record to MP4
cvlc v4l2:///dev/video0:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:standard{access=file,mux=mp4,dst='/home/pi/Webcam_Record/MyVid.mp4'}'
record + stream
cvlc v4l2:///dev/video0:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:duplicate{dst=standard{access=file,mux=mp4,dst='/home/pi/Webcam_Record/MyVid.mp4'},dst=standard{access=http,mux=ts,mime=video/ts,dst=:8099}}'
Format filenames, timestamps
You can also use formatted string for filenames. Prefix command like this:
cvlc --sout-file-format v4l2:///dev/video0:<...> dst='/home/pi/Webcam_Record/%F_%T_MyVid.mp4'}
It will produce a file named YYYY-MM-DD_HH:MM:SS_MyVid.mp4 (: are authorized in unix filenames, but not in windows filenames)
4. Make RaspberryPi3+ a Wifi access point
If you have no existing network to connect your Pi to:
You can follow instructions from official RaspberryPi3+ website : https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md
Otherwise, if you already have a network you can connect to your pi using its IP.
See part 3
On any other device, you can use VLC to access your RaspberryPi3+ VLC
stream : vlc http://<raspberrypi-ip>:8099
5. Script at startup
You can put many commands into a bash file my_bash_file.sh.
For instance :
#!/bin/bash
# auto stream launch + led off
#cvlc -vvv for verbose debug
# change this value to adapt to your webcam device number
deviceNb=0
# force video format + led off
v4l2-ctl -d${deviceNb} --set-fmt-video=width=1920,height=1080,pixelformat=1 --set-ctrl=led1_mode=0
# if delay needed
# cvlc v4l2:///dev/video${deviceNb}:chroma=h264 :input-slave=alsa://hw:1,0 :live-caching=2500 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:standard{access=http,mux=ts,mime=video/ts,dst=:8099}'
# no delay
cvlc v4l2:///dev/video${deviceNb}:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:standard{access=http,mux=ts,mime=video/ts,dst=:8099}'
Basic method
You can then make the rc.local script use your custom script to be executed at startup.
You can follow instructions from official RaspberryPi3+ website : https://www.raspberrypi.org/documentation/linux/usage/rc-local.md
Another method : Create a deamon service
We will create a "webcam-stream" service, assuming all necessary bash commands are located /home/pi/Webcam_Record/vlc_webcam_stream_service.sh
cd /lib/systemd/system/
sudo nano webcam-stream.service
And write in it:
[Unit]
Description=Custom Webcam Streaming Service
After=multi-user.target
[Service]
Type=simple
ExecStart=/home/pi/Webcam_Record/vlc_webcam_stream_service.sh
Restart=on-abort
[Install]
WantedBy=multi-user.target
Make the service file and the script executable:
sudo chmod 644 /lib/systemd/system/webcam-stream.service
chmod +x /home/pi/Webcam_Record/vlc_webcam_stream.sh
Allow VLC to be excuted as root:
sudo sed -i 's/geteuid/getppid/' /usr/bin/vlc
Reload deamons and enable our service:
sudo systemctl daemon-reload
sudo systemctl enable webcam-stream.service
Check it is recognized and working:
sudo service webcam-stream status
sudo service webcam-stream start
You can check with another computer that the video is correctly streamed.
Note that the webcam won't be available while the service is running.
Once you're done, you can connect to the RaspberryPi3+ wifi access point and access your video stream.
6. [EDIT] Additional commands : infinite loop recording & split video
The following bash scripts allows infinite recording of 15 s long videos with timestamped filenames and streaming
#!/bin/bash
# auto stream launch + led off
#cvlc -vvv for verbose debug
# adapt to video device name
deviceNb=1
# loop duration
duration=15
#infinite recording
#loopOption=
loopOption=--loop
# force video format + led off
v4l2-ctl -d ${deviceNb} --set-fmt-video=width=1920,height=1080,pixelformat=1 --set-ctrl=led1_mode=0
# if delay needed :live-caching=2500
cvlc --sout-file-format --run-time=${duration} ${loopOption} v4l2:///dev/video${deviceNb}:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100,threads=4,audio-sync=1}:duplicate{dst=standard{access=file,mux=mp4,dst='/home/pi/Webcam_Record/%F_%T_Spy.mp4'}:dst=standard{access=http,mux=ts,mime=video/ts,dst=:8099}'
7. [EDIT] Program execution at a given instant
EDIT 04 aug 2018
To launch the execution today at 14:00, you can use the following command:
./my_vlc_webcam_script.sh | at 1400
See the at command manual for further details.
8. TROUBLESHOOTING
EDIT 07 jul 2018
I recently ran into VLC error after a dist-upgrade:
VLC media player 2.2.6 Umbrella (revision 2.2.6-0-g1aae78981c)
[00acb230] pulse audio output error: PulseAudio server connection failure: Connection refused
The solution I found is to launch VLC in GUI mode and change the default audio device to ALSA (instead of Automatic). I can also be done in command line.
See the solution found here VLC issues with PulseAudio
cvlc -A alsa,none --alsa-audio-device default
You need the vcodec= for video to work and deinterlace if you want that.
cvlc v4l2:///dev/video0:chroma=h264
:input-slave=alsa://hw:1,0
:live-caching=2500
--sout '#transcode{
deinterlace,
vcodec=mpgv,
acodec=mpga,
ab=128,
channels=2,
samplerate=44100,
threads=4,
audio-sync=1}
:standard{
access=http,
mux=ts,
mime=video/ts,
dst=0.0.0.0:8099}'

"X Error" BadAlloc GLX BadContext on IntelSandyBridge (Intel HD Graphics 3000)

I'm running a debian stable ThinkPad X1 (1294-3QG) with exactly three packages from squeeze-backports needed for the GraphicsModi:
initramfs-tools 0.99~bpo60+1
linux-base 3.4~bpo60+1
linux-image-3.2.0-0.bpo.2-amd64 3.2.9-1~bpo60
While running that kernel, starting for example paraview results in those errors:
Unrecognized deviceID 126
X Error: BadAlloc (insufficient resources for operation) 11
Extension: 154 (Uknown extension)
Minor opcode: 3 (Unknown request)
Resource id: 0x3200273
X Error: GLXBadContext 169
Extension: 154 (Uknown extension)
Minor opcode: 5 (Unknown request)
Resource id: 0x32002b0
paraview: ../../src/xcb_io.c:183: process_responses: Zusicherung »!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))« nicht erfüllt.
Somewhere on the net, I found the hint to offer the memory settings in the xorg.conf, but that did not solve my problem.
Starting within the current stable kernel works fine.
Running glxgearsresults similar:
Unrecognized deviceID 126
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 27
Current serial number in output stream: 29
I further tried, to solve the problem by updating xserver-xorg-video-intel (and all dependencies libdrm-intel1 libxfont1, xserver-common, xserver-xorg, xserver-xorg-core, xserver-xorg-input-evdev, xserver-xorg-video-fbdev and xserver-xorg-video-vesa) to backports, but that was not prosperous.
Additional, I found the entry
[drm] MTRR allocation failed. Graphics performance may suffer.
in the output of dmesg.
I had the same issue on self-made server station with Intel i7 2700k (which has Intel HD 3000) running Debian Stable 6.0.4 (squeeze) x64. Basically I knew that this platform has loads of problems with unix systems (as always intel GPU does), but it purpose is server, so on-board graphic is fair enough for that. Anyways I wanted someday to run just a move (on TV connected via HDMI*/VGA), so I installed gnome-core with gdm3 to run manually.
With kernel 2.6.32-5-amd64 everything was excellent, besides few things, which forced me to upgrade kernel:
SSD support (added & improved from linux-image-2.6.33)
HDMI - no devices was recognized, couldn't add & change resolution (cvt xrandr).
So I added squeeze-backports to sources.list and upgraded only kernel (same what you did).
After that HDMI connection works great, but I noticed slow refresh rate - tearing during loading gdm3 login screen and after. I checked dmesg and kernel messages for some infos
cat dmesg | grep failed && cat dmesg | grep drm && cat /var/log/messages | grep failed && cat /var/log/messages | grep drm - found same. Than I run glxgears and found same error.
I was digging net for few days after some solutions and ideas.
Found many useless things about allocating RAM (enable_mtrr_cleanup) etc.
Basically for my hardly ever cinematic needs it wasn't tragedy, but I like when everything is perfect, so I still was working around to fix it.
And at last! Got it solved! Problem was not with the RAM or new kernel itself.
I have to mention here, that I compiled Debian kernel myself - 3.2 based on settings from previous install.
I removed also all unneeded libs for my architecture (i.e. libdrm for nvidia radeon and others - even VESA!!!)
I added just for a moment wheezy (testing) repositories, upgraded and installed new packages with dependences as root (only this ones):
echo deb http://ftp.pl.debian.org/debian/ testing main contrib non-free >> /etc/apt/sources.list
apt-get update
apt-get install --reinstall -t testing libdrm2 libdrm-intel1 xserver-xorg-video-intel xserver-xorg-core libgl1-mesa-glx libgl1-mesa-dri mesa-utils
dpkg-reconfigure xserver-xorg
That fixed all problems with rendering and allocation on Intel GPU :)
Think it should works for you and everyone with Intel GPU-s. Don't forget to remove wheeze (testing) from sources.list when you are done.
Regards, T_Send.
I solved it now on my own by updating some mesa concerning packages. I'm running debian stable with those following packages from backports:
initramfs-tools, libdrm-intel1, libgl1-mesa-dev, libgl1-mesa-dri,
libgl1-mesa-glx, linux-base, linux-headers-3.2.0-0.bpo.1-all-amd64,
linux-headers-3.2.0-0.bpo.1-amd64, linux-headers-3.2.0-0.bpo.1-common,
linux-headers-3.2.0-0.bpo.1-common-rt,
linux-headers-3.2.0-0.bpo.1-rt-amd64,
linux-headers-3.2.0-0.bpo.2-all-amd64,
linux-headers-3.2.0-0.bpo.2-amd64, linux-headers-3.2.0-0.bpo.2-common,
linux-headers-3.2.0-0.bpo.2-common-rt,
linux-headers-3.2.0-0.bpo.2-rt-amd64, linux-image-3.2.0-0.bpo.2-amd64,
linux-kbuild-3.2, mesa-common-dev
Hoping this info will help other, too.

Resources