Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - snide

Pages: [1] 2
Installation / Re: Can't change desktop background to solid color
« on: July 03, 2018, 07:45:54 am »
I can confirm that this is happening.

Don't choose a wallpaper, choose a colour and nothing changes it keeps the old wallpaper

Regards Zeb...
Thank you for the confirmation. Nice to know it is reproducible by someone else and not just me.

I'll have a look at nitrogen, but for now I can offer 2 workarounds.
Thank you for providing workarounds.  I will keep an eye on this subject to see when/if you find the solution to the issue (assuming you will post when/if you do). Best wishes.
Should I mark this as solved or wait until the underlying issue is fixed?

Thank you.

Installation / Can't change desktop background to solid color
« on: July 02, 2018, 09:23:26 am »
Wasn't sure if I should post this here or a different forum so feel free to move it if needed. I've been using PeppermintOS since version 5. Just finished installing 9 and everything seems to be working great except that I can't change my desktop background to a solid color. I've been able to do this in every previous version. What I've done previously is rt-click on the desktop, select Change Desktop Background, click on the color box w/o clicking on any wallpaper image, select a color (usually I just use black), click OK, click Apply.  With previous versions of Peppermint the wallpaper would disappear leaving just the solid color background. Now, nothing happens -  the wallpaper image stays. Has something changed?
FYI I use a dual monitor setup, but that has been the case for me since I've used Peppermint 7 and hasn't been a problem before.

What would I need to do to adapt this procedure to a multi user environment? Let's say I have 3 users (user1, user2, user3) for whom I would like to keep personal data on a single separate DATA partition?

New Users / Re: Help a noob understand audio drivers
« on: April 05, 2016, 02:39:20 pm »
Thank all of you for your responses as they gave me some leads that I've used to do more research. I'll try to summarize what I've inferred from what I've found, much of which reinforces PCNetSpec's post.

On my mainboard, Realtek is the audio chip (codec) which provides sound. Intel Sunrise Point is the mainboard chipset. This chipset includes the HD Audio Bus controller, which is linked to the codec(s) that provide audio in the system. This information applies to HDA-compliant integrated (onboard) audio.


The Intel HD audio spec defines the architecture, link frame format, and programming interfaces used by the controller on the PCI bus and by the codec on the other side of the link (Wikipedia, Intel, others).
The OpenBSD article plainly states: "The codec is the main audio processor."
From MSDN: "The HD Audio architecture is intended to eliminate the requirement for solution-specific drivers by specifying a base register set that is uniform across all implementations," and  "...the HD Audio bus driver detects the codecs that are attached to the HD Audio controller's HD Audio Link. For each codec, the bus driver loads one function driver (if available) for each function group that it finds within the codec." Also, the "...  HD Audio Bus Driver are provided by Microsoft." (for Windows, obviously).

So theoretically a motherboard manufacturer could use any HDA-compliant codec with any HDA-compliant bus controller (chipset) and it will work with at least basic functionality w/o manufacturer-specific drivers, assuming the operating system has HDA-compliant bus drivers. This would explain why audio worked for this board in my Win 7 install (Win 7 having been around long before Intel's Sunrise Point) w/o any mfg drivers installed. I suppose if the codec or chipset mfg (VIA and Nvidia also provide chipsets - Intel hasn't always been the only one) has features (or functions) that extend outside of the HDA spec then they would provide o/s drivers to enable those functions.

IMHO, the inxi -A command is misleading when it reports the audio "Card" in my system as Intel Sunrise Point. Without a doubt, my board's audio is provided by Realtek:
  • specs page (scroll down to the audio section)
  • driver download page (select All in the choose your OS spinbox)
  • screenshot from my Win 7 install on this system showing the audio codec drivers I installed from Realtek's site:
Sunrise Point is certainly the chipset name, and the chipset contains (or is) the HDA bus controller, which hooks into the codec.  So it appears that the inxi command identifies the bus controller, not the codec. On the other hand, the aplay -l command actually lists the codec(s) available, even though it doesn't list the codec mfg/vendor.

snd_hda_intel would then be the operating systems's HDA bus controller driver. I assume this driver would show up in every system using HDA-compliant onboard audio. I happened to have an old VIA-based chipset PC and a nVidia-based chipset PC on which I ran a Peppermint Live USB stick and sure enough:
Spoiler (click here to view / hide)

Spoiler (click here to view / hide)

So, I am still curious to see what, if any, difference installing the Linux driver from Realtek's site would make. In Windows I know installing the driver adds codec vendor identification in the Device Manager (pictured above - it didn't specify Realtek as the vendor until after the driver was installed) and adds an audio control panel which probably doesn't do anything different than what Windows' native one does, but is easier to access and, IMHO, understand:

But I couldn't make much sense of Realtek's Linux install instructions on my skim through, other than it ties in with ALSA and snd_hda_intel. And while I can roll-back Windows drivers in my sleep, I certainly wouldn't know the first thing about rolling back drivers in Linux.

So if you've made it this far, hopefully you've learned something new, and maybe even helpful, and didn't get a headache doing it (and don't see many flaws in my logic!). Unfortunately, I am puzzled why I've seen so many posts on various sites of people with audio issues in Linux. Obviously I am clueless when it comes to drivers, and I assume Linux handles that stuff very differently than Windows, but I wonder if the snd_hda_intel driver is less general/generic than the equivalent Windows driver. Theoretically, it should just work, assuming everything is HDA compliant. Oh well, another topic for another day (or not). At least now I understand (I think) what is being reported and why in regards to my audio.

PCNetSpec, sorry to append a solved thread, but I think this may be related to the cleanup. This is my update list today:

I noticed the linux-libc-dev package had a version number that corresponds to an old kernel - should I remove that also, or will that break something?

New Users / Help a noob understand audio drivers (SOLVED)
« on: March 15, 2016, 10:27:08 am »
As a windows user for almost 20 years I have developed the compulsion, for better or worse, to always install the latest available driver whenever I can. I suppose it came from being a gamer in the early days of Win 98 (and Win Vista) when driver updates were nearly a necessity to fix issues. Nowadays I don't game much anymore, but I don't care if the generic or MS-supplied driver works fine, I still gotta get the latest from the manufacturer website, if such exists. I will frequently update to a newer version when I learn one is available, whether or not I actually need it; I can't help it!

Based on what I've seen/read so far, and I'm sure I haven't properly understood most of that, drivers for Linux (are they even called drivers in Linux?) are built-in, and for the most part, you don't update them. If it works, don't fix it (anathema!). Now, my audio seems to work fine - I tested it for YouTube in Chrome and for movies in VLC. But it is a head-scratcher for me to see Intel Sunrise Point for audio instead of RealTek  :o. I start to get the heebie-jeebies - it takes a monumental effort to beat down the urge to try installing RealTek drivers from their site (except that the instructions are a bit bewildering for me). Anyway, here are the results of some audio device commands I found while perusing the forums (I do see a reference to ALC887, which is my audio chip, using the aplay command) - I hope it isn't bad form to use the spoiler tags:
Spoiler (click here to view / hide)

So I guess I'd like to know why doesn't Realtek appear as the vendor? What is Intel Sunrise Point audio?  Is it advisable to install Realtek drivers from their site? How do I resist the urge to leave well enough alone!?!? (arrgh... must ... resist.... tweaking...) So many questions, so little time.

I'm sorry for not being clear, but my question about the cleanup instructions was in no way at all criticism about Peppermint OS or your excellent instructions. At worst, maybe a criticism of the omission of that step by the author of the Ubuntu page that explains their kernel update process.

In fact, I am very appreciative of your assistance, and impressed with the speed and expertise of the responses that I've seen in these forums overall. Before posting the question here I came across many posts (particularly in Ubuntu and Mint forums) about this problem in the 20-30 minutes I spent searching for solutions to this issue. Nowhere did I notice a solution, at least one that I could comprehend or recognize as a solution. Geez, I had no idea one could update/upgrade the kernel without (re)installing a new operating system/distro; what a great thing!  8)

I really think it would be beneficial to have a tutorial in the one of the tutorial sections explaining this process and when/why to try it. Like I mentioned before, doing this solved my graphics and NIC issue. In my opinion this also seems an excellent way of enhancing the LT part of LTS for those of us (not many I'm sure) that don't want to fully (re)install an upgraded/new distro every 6 months or year or so. I wish I understood Peppermint/Linux so I could write a tutorial, but I just don't get it. Yet.

So thanks again for your help and keep up the great work!

Neither Ubuntu or Peppermint push this as an update, so when would a "simple user" come across this in the first place ?
Well, when they want to use Peppermint OS on their Sky Lake system  :).  I surely can't be the only one!
Thanks again!

Thanks again PCNetSpec for your assistance. The corrected command returned nothing.
Marking as solved, but would still like to know what harm there would be in not cleaning up with the massive commands you gave me earlier, and how in the world a simple user like me is supposed to know about that  ???.

Ugh, a bug that affects lefties.  :o Unconscionable! >:(
Thanks for the link. I edited the desktop.conf file - odd that selecting the option doesn't change the file, but so much of Linux is over my head.  ???
Thanks slim!

So I have "Left handed button layout" selected (checked) in the Peppermint Control Center, but every time I restart or logout/login, the button layout reverts to right handed, even though the option remains selected in the Control Center! Yes, to repeat, the "Left handed button layout" option is still selected on reboot, but I have to uncheck it and then select it again for the option to properly work. Anyone know what is going on here?

Code: [Select]
hgs@hgs-pep ~ $ dpkg -l | grep 3.16.0
hgs@hgs-pep ~ $ dpkg -l grep lts-utopic
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
ii  grep           2.16-1       amd64        GNU grep, egrep and fgrep
dpkg-query: no packages found matching lts-utopic
hgs@hgs-pep ~ $

OK. Did it. So what did I just do? And why?
Also, this message appeared for each command:
Code: [Select]
The following package was automatically installed and is no longer required:
Use 'apt-get autoremove' to remove it.
Autoremove or purge or leave alone?


There is however a little tidying up to be done .. what is the output from:
Code: [Select]
dpkg -l | grep 3.16.0
Code: [Select]
hgs@hgs-pep ~ $ dpkg -l | grep 3.16.0
ii  linux-generic-lts-utopic                                    amd64        Complete Generic Linux kernel and headers
ii  linux-headers-3.16.0-46                   3.16.0-46.62~14.04.1                    all          Header files related to Linux kernel version 3.16.0
ii  linux-headers-3.16.0-46-generic           3.16.0-46.62~14.04.1                    amd64        Linux kernel headers for version 3.16.0 on 64 bit x86 SMP
ii  linux-headers-3.16.0-62                   3.16.0-62.83~14.04.1                    all          Header files related to Linux kernel version 3.16.0
ii  linux-headers-3.16.0-62-generic           3.16.0-62.83~14.04.1                    amd64        Linux kernel headers for version 3.16.0 on 64 bit x86 SMP
ii  linux-headers-generic-lts-utopic                            amd64        Generic Linux kernel headers
rc  linux-image-3.16.0-37-generic             3.16.0-37.51~14.04.1                    amd64        Linux kernel image for version 3.16.0 on 64 bit x86 SMP
ii  linux-image-3.16.0-46-generic             3.16.0-46.62~14.04.1                    amd64        Linux kernel image for version 3.16.0 on 64 bit x86 SMP
ii  linux-image-3.16.0-62-generic             3.16.0-62.83~14.04.1                    amd64        Linux kernel image for version 3.16.0 on 64 bit x86 SMP
rc  linux-image-extra-3.16.0-37-generic       3.16.0-37.51~14.04.1                    amd64        Linux kernel extra modules for version 3.16.0 on 64 bit x86 SMP
ii  linux-image-extra-3.16.0-46-generic       3.16.0-46.62~14.04.1                    amd64        Linux kernel extra modules for version 3.16.0 on 64 bit x86 SMP
ii  linux-image-extra-3.16.0-62-generic       3.16.0-62.83~14.04.1                    amd64        Linux kernel extra modules for version 3.16.0 on 64 bit x86 SMP
ii  linux-image-generic-lts-utopic                              amd64        Generic Linux kernel image
ii  linux-signed-generic-lts-utopic                             amd64        Complete Signed Generic Linux kernel and headers
ii  linux-signed-image-3.16.0-46-generic      3.16.0-46.62~14.04.1                    amd64        Signed kernel image generic
ii  linux-signed-image-3.16.0-62-generic      3.16.0-62.83~14.04.1                    amd64        Signed kernel image generic
ii  linux-signed-image-generic-lts-utopic                            amd64        Signed Generic Linux kernel image

Code: [Select]
dpkg -l | grep lts-utopic
Code: [Select]
hgs@hgs-pep ~ $ dpkg -l | grep lts-utopic
rc  libegl1-mesa-lts-utopic:amd64             10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the EGL API -- runtime
rc  libgbm1-lts-utopic:amd64                  10.3.2-0ubuntu1~trusty2                 amd64        generic buffer management API -- runtime
rc  libgl1-mesa-dri-lts-utopic:amd64          10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the OpenGL API -- DRI modules
rc  libgl1-mesa-glx-lts-utopic:amd64          10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the OpenGL API -- GLX runtime
rc  libglapi-mesa-lts-utopic:amd64            10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the GL API -- shared library
rc  libgles1-mesa-lts-utopic:amd64            10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the OpenGL|ES 1.x API -- runtime
rc  libgles2-mesa-lts-utopic:amd64            10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the OpenGL|ES 2.x API -- runtime
rc  libopenvg1-mesa-lts-utopic:amd64          10.3.2-0ubuntu1~trusty2                 amd64        free implementation of the OpenVG API -- runtime
rc  libwayland-egl1-mesa-lts-utopic:amd64     10.3.2-0ubuntu1~trusty2                 amd64        implementation of the Wayland EGL platform -- runtime
rc  libxatracker2-lts-utopic:amd64            10.3.2-0ubuntu1~trusty2                 amd64        X acceleration library -- runtime
ii  linux-generic-lts-utopic                                    amd64        Complete Generic Linux kernel and headers
ii  linux-headers-generic-lts-utopic                            amd64        Generic Linux kernel headers
ii  linux-image-generic-lts-utopic                              amd64        Generic Linux kernel image
ii  linux-signed-generic-lts-utopic                             amd64        Complete Signed Generic Linux kernel and headers
ii  linux-signed-image-generic-lts-utopic                            amd64        Signed Generic Linux kernel image
rc  xserver-xorg-core-lts-utopic              2:1.16.0-1ubuntu1.2~trusty2             amd64        Xorg X server - core server
rc  xserver-xorg-lts-utopic                   1:7.7+7ubuntu2~trusty1                  amd64        X.Org X server
rc  xserver-xorg-video-intel-lts-utopic       2:2.99.914-1~exp1ubuntu4.5~trusty1      amd64        X.Org X server -- Intel i8xx, i9xx display driver
rc  xserver-xorg-video-modesetting-lts-utopic 0.9.0-1build1~trusty1                   amd64        X.Org X server -- Generic modesetting driver
rc  xserver-xorg-video-openchrome-lts-utopic  1:0.3.3-1build2~trusty1                 amd64        X.Org X server -- VIA display driver
rc  xserver-xorg-video-vmware-lts-utopic      1:13.0.2-3ubuntu1~trusty1               amd64        X.Org X server -- VMware display driver

Installed arandr and it does mostly what I want - now I get to learn how to run scripts at startup  8)! (and start a new topic on how to start troubleshooting my audio problem  ???)

Hah! I had beat you to the punch and already run the command you referenced.  Man, it is nice not to look at 800X600, and the formerly unrecognized ethernet port is now functioning properly.  Anyway here is inxi -F output:
Code: [Select]
hgs@hgs-pep ~ $ inxi -F
System:    Host: hgs-pep Kernel: 4.2.0-30-generic x86_64 (64 bit) Desktop: N/A Distro: Peppermint Six
Machine:   System: Gigabyte product: N/A
           Mobo: Gigabyte model: Q170M-MK version: x.x Bios: American Megatrends version: F2 date: 01/12/2016
CPU:       Quad core Intel Core i5-6600 CPU (-MCP-) cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx)
           Clock Speeds: 1: 3846.820 MHz 2: 3742.921 MHz 3: 2610.996 MHz 4: 3871.828 MHz
Graphics:  Card: Intel Sky Lake Integrated Graphics
           X.Org: 1.17.2 drivers: intel (unloaded: fbdev,vesa) Resolution: 1440x900@59.9hz, 1440x900@60.0hz
           GLX Renderer: Mesa DRI Intel Skylake DT GT2 GLX Version: 3.0 Mesa 11.0.2
Audio:     Card: Intel Sunrise Point-H HD Audio driver: snd_hda_intel Sound: ALSA ver: k4.2.0-30-generic
Network:   Card-1: Intel Ethernet Connection (2) I219-LM driver: e1000e
           IF: eth1 state: up speed: 1000 Mbps duplex: full mac: 40:8d:5c:b6:c9:22
           Card-2: Intel I211 Gigabit Network Connection driver: igb
           IF: eth0 state: down mac: 40:8d:5c:b6:c9:20
Drives:    HDD Total Size: 820.1GB (0.6% used) 1: id: /dev/sda model: ST3160812AS size: 160.0GB
           2: id: /dev/sdb model: ST3160812AS size: 160.0GB 3: id: /dev/sdc model: WDC_WD5000AAKS size: 500.1GB
Partition: ID: / size: 8.0G used: 4.2G (56%) fs: btrfs ID: /home size: 4.0G used: 445M (13%) fs: btrfs
           ID: swap-1 size: 8.59GB used: 0.00GB (0%) fs: swap
RAID:      No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors:   System Temperatures: cpu: 29.8C mobo: 27.8C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 220 Uptime: 11 min Memory: 976.1/15913.2MB Client: Shell (bash) inxi: 1.9.17
I don't think I am going to install an upstream kernel at this time, unless you think I should. I don't think I need the latest/greatest drivers drivers from Thanks to your previous links I found this site for future reference: (unless you recommend something else).  I do need to know how to extend the screens for my dual monitor setup, though. Also, do I need to change any sort of configurations or anything so that updating isn't messed up now that I have a different kernel?

Let us know if you need assistance.
That will almost be a certainty!

Thanks for  the response; I'll check out the links and see what I can figure out. Hopefully that will solve my ethernet (Intel I219-lm) and audio (realtek) issues, too.

Pages: [1] 2