It is currently Mon Apr 24, 2017 3:34 am



Welcome
Welcome to antiX-forum.

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. Registration is fast, simple, and absolutely free, so please, join our community today!


Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 16 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: How to set the default graphics driver in X?
PostPosted: Mon Mar 09, 2015 1:05 am 
Offline
User avatar

Joined: Tue Sep 01, 2009 12:48 am
Posts: 1125
The default graphics driver used to be "vesa" and all was well with the world. Now, if the console framebuffer is enabled, the default becomes "fbdev" and the resolution in X becomes the same resolution in the consoles. This is a problem if we enable the framebuffer by default (on the antiX-15 live system) to a resolution of 800x600. See attached image.

I'm writing code now to circumvent this by having the system automatically create an xorg.conf file specifying the "vesa" driver if the framebuffer is enabled and if there is no xdrvr=xxx boot parameter and if there is no graphics driver (nouveau, i915, nvidia, nouveau, radeon) already loaded. This may cause a problem with persistent systems that have the nvidia driver installed but there are simple ways to circumvent this problem so I figure we can deal with it when we encounter it. Right now, having a default X resolution of 800x600 seems unacceptable to me.

If anyone knows, how to change the default graphics driver in X back to "vesa", this would make things much easier. Thanks.


Attachments:
default-800x600.png
default-800x600.png [ 51.65 KiB | Viewed 2523 times ]

_________________
Science is the belief in the ignorance of experts.
-- Richard Feynman
Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Tue Mar 10, 2015 5:12 am 
Offline

Joined: Thu Jan 21, 2010 12:36 am
Posts: 1040
Not really sure at the moment as I have not really looked, but I will post my first place to look so at least you will get some useful information in the event my looking takes to long...

My first place to look would be in / etc/X11/ with the various directories but iirc they are mostly empty. So perhaps the main lib folders that the etc folder is supposed to expand on????

/usr/lib/X11/ and /usr/share/X11?

I really have not thought about it before. Typically to solve that default issue I make a specific xorg.conf. But obviously that is a problem because it is machine specific. I do have a script to build a standard but useful Xorg if it is of help. I use it for the multi seat computers I do, but it could be easily adapted if needed (remove the kdm update stuff) . That way I do not need to manually reconfigure every time the machine is restarted or the seats are added / removed / rearranged. It is based off automseat script if it is of useful information

_________________
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Tue Mar 10, 2015 5:35 am 
Offline
User avatar

Joined: Tue Sep 01, 2009 12:48 am
Posts: 1125
I've got code written and working that makes an xorg.conf specifying the vesa driver if there is no graphics driver loaded and no existing xorg.conf (and maybe a few other things). Generating the file in vbox took about 0.2 seconds so I don't think this is a big slowdown.

We already had a script for building an xorg.conf file at /usr/sbin/buildxconfig. I modified it and moved it to /sbin/make-xorg-conf (which goes along with /sbin/make-fstab). This seems like the long way around. It would be much better if we could just tell the xserver to use vesa as the default driver. My guess is that ours is a bit of a corner case that hasn't gotten much attention. Must newer systems use a hardware specific graphics driver and on top of that, AFAIK, not many distros are enabling the vga frame buffer by default.

_________________
Science is the belief in the ignorance of experts.
-- Richard Feynman


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Tue Mar 10, 2015 10:12 am 
Offline

Joined: Sun Aug 21, 2011 10:59 am
Posts: 994
A request for more information to clarify what is creating the need for this extra code at boot-up.

For many years, and in many distros, it has been a widely used practice to specify a resolution at the earliest stages of the boot process, without the adverse affects illustrated in the screen shot of the opening post.

Example
  • In antiX-13.2 a resolution of 800x600 is specified
  • Framebuffer is enabled (demonstrated by the on screen text size during the earliest stages of the boot process)
  • When booting to console only (no X) the resolution is 800x600
  • In console mode, mplayer can show successfully play a video using fbdev2 for video output.
  • When booting to GUI (X), framebuffer hands over to the driver for the video adaptor which uses its highest resolution without reference to (and without being restricted to) the lower resolution specified in the earlier boot process.
  • In GUI mode, mplayer can successfully show a video without explicitly specifying a video output driver (i.e. it works with X).
  • From the GUI switch to console (e.g. CTRL+ALT+F2) mplayer can run the same video using fbdev2 for video output.

Note: In neither case, (booted to console only, or to GUI) was framebuffer explicitly enabled. The action of specifying a resolution automatically enables framebuffer without affecting the defaults.

Summary
  • The defaults are used
  • Framebuffer is automatically enabled by specifying the resolution at boot-up
  • The boot resolution does not affect the GUI (X) display which works as expected
  • Framebuffer works as expected
  • MPlayer plays videos in both console mode, and GUI mode (i.e. successfully uses framebuffer or video card driver as appropriate)
  • It is a long established mechanism that does not require additional code during the boot process


What has changed in antiX-15 to make it necessary to explicitly enable framebuffer with its consequent adverse affects that require additional code to address?
  • The boot loader?
  • The kernel?
  • X-org?
  • Something else? If so, specifically what is it?


Edit: Typo


Last edited by SamK on Tue Mar 10, 2015 5:05 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Tue Mar 10, 2015 4:50 pm 
Offline
User avatar

Joined: Sun Dec 16, 2007 4:49 pm
Posts: 2124
SamK wrote:

What has changed in antiX-15 to make it necessary to explicitly enable framebuffer with its consequent adverse affects that require additional code to address?
  • The boot loader?
  • The kernel?
  • X-org?
  • Something else? If so, specifically what is it?



I believe the frambuffer setup is required for the new console decoration schemed that BitJam has been working on.

_________________
http://www.youtube.com/runwiththedolphin
eeepc 904ha antix 15 32 bit (streaming media player)
sony laptop amd 900mhz duran 512mb ram, antix 13 32-bit
lenovo s21e - 2gb ram, celeron - antiX-16 64 bit


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Tue Mar 10, 2015 8:48 pm 
Offline
User avatar

Joined: Tue Sep 01, 2009 12:48 am
Posts: 1125
*I* had already turned the framebuffer off by default due to this problem. There were vocal complaints from testers, perhaps based on the erroneous assumption that:
Quote:
The vga=xxx parameter only affects console mode. It is irrelevant to, and does not affect GUI (X-server) mode. However, because antiX boots initially to console and (when a GUI is wanted) subsequently hands over to X, an inappropriate vga=xxx parameter will cause a boot failure in both modes.
So anti asked me to enable the 800x600 framebuffer by default which leads to this problem in X.

_________________
Science is the belief in the ignorance of experts.
-- Richard Feynman


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Tue Mar 10, 2015 9:34 pm 
Offline

Joined: Thu Jan 21, 2010 12:36 am
Posts: 1040
I am still not exactly sure, nor have I had a chance to try it. However with a little bit of time it seems to me (=my next move) would be to edit (add before?) a "section Device" that would specify the vesa driver rather than the "@@XMODULE@@" that is currently there. Opening that file seems to have a list of defaults for inputs and only 1 default for displays.

If that does not work my next move would be to add a similar generic config to the xorg.conf.d directory similar to the 50-synaptic.conf that is in there or the 10-evdev.conf file. Both those seem to have an if this than that, otherwise try and match next. This seems to be repeated till something is found else X crashes.

_________________
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Wed Mar 11, 2015 8:16 am 
Offline

Joined: Sun Aug 21, 2011 10:59 am
Posts: 994
BitJam wrote:
There were vocal complaints from testers...
I don't recall this. Will you help by posting the forum links to this feedback so I can become familiar with it (or just as possible, to refresh my fallible memory).


dolphin_oracle wrote:
I believe the frambuffer setup is required for the new console decoration schemed that BitJam has been working on.
BitJam wrote:
...enable the 800x600 framebuffer by default which leads to this problem in X.
Can you confirm the suggestion by dolphin_oracle? If it is correct it will enable the discussion to continue with the certainty that the cited problem with X resolution is a symptom of console decoration rather than framebuffer being the primary cause.

One acid test for this will be to run a test in which all aspects of console decoration are removed from the antiX-15 boot process. If that enables/restores the "standard" boot behaviour (as per 13.2 and other distros) the cause of the problem will be unequivocally established, which in turn will point to other ways of addressing the matter.


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Thu Mar 12, 2015 1:27 pm 
Can using framebuffers lead to conflicts with / etc/ modprobed/ fbdev-blacklist.conf if you have a machine such as my old SIS machine?


Top
  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Fri Mar 13, 2015 9:55 am 
Offline

Joined: Sun Aug 21, 2011 10:59 am
Posts: 994
Re
SamK wrote:
BitJam wrote:
There were vocal complaints from testers...
I don't recall this. Will you help by posting the forum links to this feedback so I can become familiar with it (or just as possible, to refresh my fallible memory).
In a trawl of the forum I have been unable to find these posts. It will be helpful if the links to the feedback are posted.

The trawl did turn up some pertinent information.



Re
SamK wrote:
dolphin_oracle wrote:
I believe the frambuffer setup is required for the new console decoration schemed that BitJam has been working on.
BitJam wrote:
...enable the 800x600 framebuffer by default which leads to this problem in X.
Can you confirm the suggestion by dolphin_oracle? If it is correct it will enable the discussion to continue with the certainty that the cited problem with X resolution is a symptom of console decoration rather than framebuffer being the primary cause.

One acid test for this will be to run a test in which all aspects of console decoration are removed from the antiX-15 boot process. If that enables/restores the "standard" boot behaviour (as per 13.2 and other distros) the cause of the problem will be unequivocally established, which in turn will point to other ways of addressing the matter.
Abstract from this post
post38193.html#p38193

SamK wrote:
BitJam wrote:
...fbcondecor code gets fooled. It sets the console decoration using the vga=xxx framebuffer then the video module gets loaded creating a different frame buffer and we lose the decoration.
[...]
While there are ways of dealing with this...

It seems we are unnecessarily creating our own problems for which we then have to invent resolutions/workarounds.

From your earlier comments it looks as though we agree that shipped defaults for the crucial boot role should be as catholic as practicable. Hopefully this is not an unintentional misrepresentation of your view.

Console decoration is essentially eye-candy. It is not required to achieve a successful boot up. In such a case it is suboptimal to allow it to fundamentally influence the boot up process. When using it as a shipped default is adversely affecting reaching the agreed goal, it is a strong argument in favour of it becoming something the user elects to use, rather than something from which the user has to opt out. In this way its constraints do not have to be accommodated at the earliest stage of the boot up, for every user irrespective of whether or not they use it.
From this it is reasonable to conclude (with extremely high levels of certainty) that fbcondecor is the causing the cascade of issues and workarounds rather than the action of specifying any particular screen resolution or conventional use of framebuffer.

Note: despite having limited personal free time, and should absolute certainty be required, if a further version of antiX-15 is made available from which all aspects of fbcondecor (including patch) have been removed, I will test on a range of kit and report the findings, if requested to do so.



Re Console Decoration
Abstract from this post
post39774.html#p39774

BitJam wrote:
You might wonder why we added this eye-candy bling to antiX which is supposed to be lean and mean. The answer is that it is bling for the virtual consoles and we want to provide good support for console-only use. I think it serves a useful purpose to let you know visually which virtual console you are on.
[...]
Each workspace has a different background image.
[...]
I spend a lot of my development time using the virtual consoles and I much prefer working with fbcondecor enabled. With the framebuffer and fbcondecor I can often be much more productive in the virtual consoles then in X.
Although there are no figures that I know of on this, it is likely the percentage of the antiX user-base that work in GUI mode is exceedingly close to 100%. The number of users that work exclusively or predominately in the console is likely to be the tiniest of fractions of the total antiX user-base. That should not be interpreted as meaning a minority should be ignored. When the feature is incidental/inessential (e.g. eye candy bling), and is relevant to very few users, and is introducing adverse affects for every user (current problems), it is only right to consider its value.

Prior to the antiX alpha series, when a user chooses to use fbcondecor on their own system(s), it is entirely the responsibility of that user to handle any issues that arise. The number of problems may well be fewer for a console only user than a GUI only user. The case is different for a distro. There are potentially many thousands of users, with a myriad of different hardware configurations. It is the developers plus user community that will have to handle any problems that crop up. At a distro level the potential scope of issues that might be encountered is greater than that of an individual user.

We do not know what the full scope or extent of those issues might be, because we cannot know in advance what we do not know now. It is clear even at this alpha stage that problems are beginning to emerge for which there is comparatively little published information. Rather than address the cause of the problems, antiX is moving away from the accumulated published knowledge that has a proven to be reliable over many years and many distros, and is currently considering introducing workarounds to the "standard" practice. There is a risk that antiX might be placing itself in a position where it cannot make full use of known good, documented practices and fixes.

In cases where a user habitually uses multiple consoles, it might be preferred and helpful to have a visual key to distinguish which workspace is being used, although switching via the key combination serves as a hint. As is often the case, Linux helps with this by offering more than one method of providing a visual clue. The following are extensions of a technique currently employed in antiX-13.2 and antiX-15-alpha. Any one, or combination of them might be used on a per console basis.
  • A different background colour
  • A different text colour
  • A different text size
  • A different prompt colour
  • A different prompt wording (possibly including the console identity)
Because these are done at the end/after boot-up (rather than at the very start of boot-up) they have zero impact on the boot process and they are risk free.

Summary of benefits of an alternative method of console decoration
  • The desired visual differentiation is achieved
  • antiX retains the standard and unmodified boot practices
  • antiX is able to make full use of published reference material
  • The antiX community is able to continue offering advice and guidance based on known standard practice
  • The current adverse affects are eliminated
  • Risk is eliminated
  • Has no adverse affect on the majority group of GUI (X) only users
  • Is able to be automatically or manually switched on or off by the user after boot-up i.e. toggled without a reboot
  • Is able to be tailored to suit the preference of an interested user
  • Caters for the minority group of console only (no X) users
  • The entire screen remains usable rather than reduced to accommodate the unusable areas of a displayed background image
  • Reduced storage footprint (ISO and installed and live) as additional apps and support files are not required
  • Reduced maintenance as kernel patching and workaround code are not required
  • Allows a user who currently uses fbcondecor to choose to continue to do so by continuing to provide their own patched kernel and files



Conclusion
A win-win outcome is achievable by making a minor change to way in which console decoration is provided within antiX-15.


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Sat Mar 14, 2015 12:09 am 
Offline
Site Admin
User avatar

Joined: Tue Sep 11, 2007 4:55 pm
Posts: 5782
Location: Greece
The kernel set up we have been using for antiX-14/15 with fbcondecor 'eye-candy' will not change. We will keep to using it in the kernel. As has been pointed out, there are options to have it turned off (either default) or through choosing the no vga option in F7 on a cd. What we default to can be up for discussion.

To test mplayer in a console, I created an iso antiX-base Jessie with the standard Debian kernel and the result seems to be the same as with our fbcondecor kernel. mplayer in a console doesn't work with our kernels, nor with the debian Jessie one. It is supposed to work, but it doesn't. Maybe this has something to do with our choice not to use systemd and nothing to do with fbcondecor?
We will really only know once we test out a debian Jessie live iso (if there is one) and compare. Then we can really 'prove' that including fbcondecor is causing issues outlined in SamK's post.

Jessie has brought in a huge number of changes under the hood that the 'normal' end user neither cares about, nor notices. 'As long as I can do what I could before' is not as easy to implement as it seems, especially since systemd junk got added, amongst other 'improvements'.

We will make sure as much as we can that antiX-15 will remain a mean and lean light distro that is up to date and appealing. That means some tough choices will have to be made. PI and <128MB RAM is no longer a possibility on a Jessie base. Most distros (including ones that claim to be light) have even dumped support for PII/PIII and less than 1GB RAM. The fact that someone (me) can run antiX-15-beta with a 3.19.1 kernel on an old Dell Latitude crt PIII with 384 MB RAM (idle it shows 46MB usage) is a success IMO despite iceweasel or any other modern browser eating all the memory.

_________________
Philosophers have interpreted the world in many ways; the point is to change it.


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Sat Mar 14, 2015 12:40 pm 
Offline

Joined: Sun Aug 21, 2011 10:59 am
Posts: 994
anticapitalista wrote:
To test mplayer in a console, I created an iso antiX-base Jessie with the standard Debian kernel and the result seems to be the same as with our fbcondecor kernel. mplayer in a console doesn't work with our kernels, nor with the debian Jessie one. It is supposed to work, but it doesn't.
I've managed to establish the reason for this.

Using the most recent Debian8 weekly build XFCE ISO (Jessie Testing)

mplayer is now mplayer2
Code:
apt-cache search ^mplayer
mplayer2 - next generation movie player for Unix-like systems
mplayer2-dbg - Debugging symbols for mplayer2
mplayerthumbs - video thumbnail generator using mplayer


The following abstract describes mplayer2 supports fbdev (same as mplayer)
Code:
apt-cache show mplayer2
[...]
Another big feature of MPlayer is the wide range of supported output
drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev...


Install mplayer2
Code:
apt-get install mplayer2


Verify which video output drivers are avilable
Code:
mplayer --vo=help
MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
Available video output drivers:
   vdpau   VDPAU with X11
   xv   X11/Xv
   gl3   OpenGL 3.x
   gl   OpenGL
   x11   X11 ( XImage/Shm )
   sdl   SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)
   caca   libcaca
   v4l2   V4L2 MPEG Video Decoder Output
   null   Null video output
   directfb   Direct Framebuffer Device
   yuv4mpeg   yuv4mpeg output for mjpegtools
   png   PNG file
   jpeg   JPEG file
   gif89a   animated GIF output
   tga   Targa output
   pnm   PPM/PGM/PGMYUV file
   md5sum   md5sum of each frame
   gl_nosw   OpenGL no software rendering
Note: fbdev and fbdev2 are not listed

There is obviously inaccurate and misleading information about mplayer2 in Debian8.

This means testing in a console environment using mplayer2 is no longer useful.


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Sat Mar 14, 2015 5:54 pm 
Offline

Joined: Sun Aug 21, 2011 10:59 am
Posts: 994
anticapitalista wrote:
Maybe this has something to do with our choice not to use systemd and nothing to do with fbcondecor?
The above discovery means systemd can be ruled out as the cause. The lack of framebuffer support in mplayer2 accounts for the observed behaviour of being able to play a video in the GUI (X) but not in the console (no X) in antiX-14/15. It is a regrettable decision. It was a most useful feature.


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Mon Mar 16, 2015 9:03 am 
Offline

Joined: Sun Aug 21, 2011 10:59 am
Posts: 994
The following should not be interpreted as a dogmatic attempt to prove anyone (me included) is either right or wrong. The only motivation is to use this alpha/beta stage to ensure we understand where the problems are rooted, and are able to make choices based on that knowledge. It is done with the best interests of antiX as the only focus.


anticapitalista wrote:
...there are options to have it turned off (either default) or through choosing the no vga option in F7 on a cd.
The capability to switch it on/off may not provide the 100% certainty that tests with it removed will show. In order to accommodate the two states antiX must include the kernel patch, software, workarounds, etc. This means antiX will include elements that move it away from the standard adopted by 13.2 and other distros, even when the off option is selected.

If "...choosing the no vga option in F7..." means specifying no screen resolution, do you mean producing a console mode resolution of 80x25? If so then as described in post39472.html#p39472 this boots OK but the resolution is so low that the system is severely limited and practically unusable in console mode.


anticapitalista wrote:
We will really only know once we test out a debian Jessie live iso (if there is one) and compare. Then we can really 'prove' that including fbcondecor is causing issues outlined in SamK's post.
It is possible to get that information from what is presently available.

To try and help with this, the following are the results of such tests. They record the outcome after installing to hard disk the most recent weekly build of the Debian8 beta ISO. It is the XFCE version. It was installed to real physical hardware rather than a virtual machine.

The test hardware is able to boot using a vga screen resolution greater than 800x600.

Immediately after installation inxi was installed


TEST1
Boot code: none
Outcome: boots as expected to GUI (X)

Code:
inxi -c0 -G
Graphics:  Card: Intel Mobile 915GM/GMS/910GML Express Graphics Controller
           Display Server: X.Org 1.16.4 drivers: intel (unloaded: fbdev,vesa) Resolution: [email protected]
           GLX Renderer: Mesa DRI Intel 915GM x86/MMX/SSE2 GLX Version: 2.1 Mesa 10.3.2



TEST2
Boot code: vga=788
Outcome, boots as expected to GUI (X)

Initially boots using 800x600 as indicated by the on-screen text. Very quickly (2ish seconds) it changes to a higher resolution as indicated by the on screen text. Here it spends the rest of the boot up time setting everything up. The text display then hands over to the GUI and the desktop is displayed.
Code:
inxi -c0 -G
Graphics:  Card: Intel Mobile 915GM/GMS/910GML Express Graphics Controller
           Display Server: X.Org 1.16.4 drivers: intel (unloaded: fbdev,vesa) Resolution: [email protected]
           GLX Renderer: Mesa DRI Intel 915GM x86/MMX/SSE2 GLX Version: 2.1 Mesa 10.3.2
Note: although vga= is deprecated in GRUB2 it is honoured and works.


TEST3
Boot code: set gfxpayload=800x600x16
Outcome, boots as expected to GUI (X)

Initially boots using 800x600 as indicated by the on-screen text. Very quickly (2ish seconds) it changes to a higher resolution as indicated by the on screen text. Here it spends the rest of the boot up time setting everything up. The text display then hands over to the GUI and the desktop is displayed.
Code:
inxi -c0 -G
Graphics:  Card: Intel Mobile 915GM/GMS/910GML Express Graphics Controller
           Display Server: X.Org 1.16.4 drivers: intel (unloaded: fbdev,vesa) Resolution: [email protected]
           GLX Renderer: Mesa DRI Intel 915GM x86/MMX/SSE2 GLX Version: 2.1 Mesa 10.3.2



In each of the above three tests everything works as expected without any hitch or workaround. While the Debian boot loader is GRUB2 v antiX-15-Live isolinux/syslinux the results are relevant. The Debian boot implementation is what might be termed "standard" and exhibits none of the resolution issues present in antiX-15. It is evident that setting a screen resolution in the "standard" manner is not the cause or source of the problems currently being faced in antiX-15.

In short the above tests demonstrate the current antiX-15 issues do not stem from the tested Debian boot process. In this case comparing against an equivalent live version of Debian8 (if it is ever produced) will be of limited value (if any).

It is possible (although highly improbable) the outcome of such a test might indicate a problem presently exists with either or both syslinux/isolinux. If that is the case, one would expect to see current bug reports of issues when specifying the screen resolution as a parameter. Specifically, there are none in either Debian Testing (Jessie) or Debian Unstable bug tracking systems and cannot find anything in recent Syslinux mailing list.

There are two major differences (that I am aware of) between the Debian and antiX configurations.
  • Unlike antiX-15, Debian8 does not include fbcondecor in the boot process and kernel
  • Unlike antiX-15, Debian8 has not moved the video drivers into initrd
The only 100% certain way of establishing whether either or both are contributing to the problems is to directly compare antiX-15 with them included v antiX-15 with them excluded. Having investigated the non-antiX elements, these antiX specific elements have not yet undergone the same investigation to rule them out.


Off Topic
Incidental info only; this post was made from Iceweasel in Debian8 XFCE



Edit: Added that the installation was done on physical hardware rather than a virtual machine.


Top
 Profile  
 
 Post subject: Re: How to set the default graphics driver in X?
PostPosted: Thu Apr 16, 2015 3:11 am 
Offline

Joined: Thu Feb 09, 2012 7:29 am
Posts: 1085
BitJam, I found this -----v in archwiki https://wiki.archlinux.org/index.php/Xorg

Quote:
etc/X11/xorg.conf.d/10-monitor.conf
=================
Section "Monitor"
Identifier "Monitor0"
EndSection

Section "Device"
Identifier "Device0"
Driver "vesa" #Choose the driver used for this monitor
EndSection

Section "Screen"
Identifier "Screen0" #Collapse Monitor and Device section to Screen section
Device "Device0"
Monitor "Monitor0"
DefaultDepth 16 #Choose the depth (16||24)
SubSection "Display"
Depth 16
Modes "1024x768_75.00" #Choose the resolution
EndSubSection
EndSection


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 16 posts ]  Go to page 1, 2  Next


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
suspicion-preferred