Bug 1615062 - [gl] no GLX support present
Summary: [gl] no GLX support present
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 29
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-12 00:19 UTC by George R. Goffe
Modified: 2018-09-24 15:55 UTC (History)
16 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-09-24 13:10:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
tar.gz file containing Xorg.0.log and output of lspci -vvv (16.98 KB, application/x-gzip)
2018-08-12 04:14 UTC, George R. Goffe
no flags Details
flat file; no compression... (54.91 KB, text/plain)
2018-08-13 16:01 UTC, George R. Goffe
no flags Details

Description George R. Goffe 2018-08-12 00:19:07 UTC
Description of problem:

Updated this system today. Packages included libglvnd'*'. Noticed that mplayer faild with the messages below. Tried other videos with the same result. Re-compiled mplayer from their source repo and tried again. Same result. Tried other videos with the same result.

I am also unable to use dnf to downgrade these packages (libglvnd'*'; 10 in number by the way).

Version-Release number of selected component (if applicable):

rpm -q libglvnd-glx
libglvnd-glx-1.1.0-1.fc29.x86_64
libglvnd-glx-1.1.0-1.fc29.i686

How reproducible:

always

Steps to Reproduce:
1.mplayer -nosound -ao pulse -vo gl  -fs -zoom -idx  <requested video>
2.
3.

Actual results:


Expected results:


Additional info:

mplayer -nosound -ao pulse -vo gl  -fs -zoom -idx  Spotting_Bogus_Claims.mp4
MPlayer SVN-r38114-8 (C) 2000-2018 MPlayer Team
224 audio & 453 video codecs

Playing Spotting_Bogus_Claims.mp4.
libavformat version 58.17.101 (internal)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x562cfabf3ca0]Protocol name not provided, cannot determine if input is local or a network protocol, buffers and access patterns cannot be configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
VIDEO:  [H264]  640x360  24bpp  25.000 fps  271.6 kbps (33.2 kbyte/s)
[gl] no GLX support present
Error opening/initializing the selected video_out (-vo) device.
No stream found.


Exiting... (End of file)

Comment 1 leigh scott 2018-08-12 02:30:26 UTC
Without any X logs and hardware and DE info this issue will closed as 'insufficient info'

Comment 2 George R. Goffe 2018-08-12 04:14:46 UTC
Created attachment 1475283 [details]
tar.gz file containing Xorg.0.log and output of lspci -vvv

Leigh,

Thank you for your response...

What logs? 
  Xorg.0.log?

Hardware? lspci -vvv output?

DE?

Here are two of the logs.

George...

Comment 3 leigh scott 2018-08-12 06:49:53 UTC
Your intel card is using vesa, this points to a xorg or kernel issue IMO

[   270.061] (II) VESA: driver for VESA chipsets: vesa
[   270.062] (EE) open /dev/dri/card0: No such file or directory
[   270.062] (WW) Falling back to old probe method for modesetting
[   270.062] (EE) open /dev/dri/card0: No such file or directory
[   270.062] (II) Loading sub module "fbdevhw"
[   270.062] (II) LoadModule: "fbdevhw"
[   270.146] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[   270.156] (II) Module fbdevhw: vendor="X.Org Foundation"
[   270.156] 	compiled for 1.20.1, module version = 0.0.2
[   270.156] 	ABI class: X.Org Video Driver, version 24.0
[   270.159] (EE) Unable to find a valid framebuffer device
[   270.159] (WW) Falling back to old probe method for fbdev
[   270.159] (II) Loading sub module "fbdevhw"
[   270.159] (II) LoadModule: "fbdevhw"
[   270.160] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[   270.160] (II) Module fbdevhw: vendor="X.Org Foundation"
[   270.160] 	compiled for 1.20.1, module version = 0.0.2
[   270.160] 	ABI class: X.Org Video Driver, version 24.0
[   270.160] (EE) open /dev/fb0: No such file or directory
[   270.161] (EE) Screen 0 deleted because of no matching config section.
[   270.161] (II) UnloadModule: "modesetting"
[   270.161] (EE) Screen 0 deleted because of no matching config section.

Comment 4 Dave Airlie 2018-08-13 07:31:28 UTC
nomodeset on command line.

Comment 5 George R. Goffe 2018-08-13 16:01:57 UTC
Created attachment 1475611 [details]
flat file; no compression...

Dave,

Are you suggesting that I use "nomodeset" for the boot commandline?

I am already using that option.

Are you suggesting that I have used it and should try NOT using it?

I just rebooted. My kde desktop is not working as I am used to. Screen 0 (laptop) is too small for my setup. Screen 1 is where I do all my work but it's not configured correctly now.

I tried running mplayer now and it appears to be working but X11 has generated an error message (see below).

I'm including my Xorg.0.file so you can see how the system reacted without "nomodeset".

Do you need other information?

George...

Comment 6 Nicolas Chauvet (kwizart) 2018-08-13 16:58:14 UTC
You should not use nomodeset on intel

Why the modesetting driver failed to initialize ?
[    59.679] (EE) modeset(0): eglInitialize() failed
[    59.681] (EE) modeset(0): glamor initialization failed

Seems you have a very broken installation.
Did you tried to install the proprietary nvidia driver using the installer or else ?

Comment 7 George R. Goffe 2018-08-13 20:25:35 UTC
Nicolas,

When I bought this system...around 2010, I tried the proprietary nvidia driver. It didn't work well because of my constant upgrade activity which would break it. 

How is this installation broken? What is broken? X11? KDE?

George...

Comment 8 Jan Kurik 2018-08-14 10:32:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 9 Nicolas Chauvet (kwizart) 2018-09-24 13:10:51 UTC
As said in c#4 this is because you are using nomodeset on kernel boot
Please avoid this and eventually report the issue why you would need this instead.

Comment 10 George R. Goffe 2018-09-24 15:55:10 UTC
Nicolas,

As you know, things move slowly in the software fix area of this industry. I'm sure that I have reported this problem some time ago. I believe that it was suggested that I use "nomodeset" at this time.

In my environment I have two monitors. 1 came with my system and 1 is a Samsung TV (27"). I don't use the system monitor because it's too small. I have directed KDE to use only the "Big" monitor. Without nomodeset, both screens are selected and KDE goes a little wild. Debuging this is slow, developer response has been slow, the bug report(s) get closed at "EOL". Nothing gets fixed. Argh!

This is why I use "nomodeset". It's been several years now. Things work fairly well... Sometimes other bug reports are triggered... like this one.

The good news is that mplayer is working fine... I changed some switches in the invocation command line.

George...


Note You need to log in before you can comment on or make changes to this bug.