Windows 10 defaults to 8-bit color depth automatically.

I’ve recently configured my Apple Mac Pro to dual-boot with Windows 10. I’d done this a couple of times before (with a Mac Mini + Win7) and in the past it all went pretty smoothly. The Mac Pro is a much more powerful machine and offers AMD FirePro D300 GPUs (Display Adapters). And the D300 is pretty powerful too (or so I thought. ) Its ‘Properties’ window shows me a wide range of display modes and refresh rates — all of which apparently support 32-bit colour.

BUT. no matter which setting I choose in the Properties dialog, Windows itself invariably reports only 8-bit colours — and to my eyes, the colour palette definitely does look a bit limited. Is this a bug in Windows 10 or is it something to do with the fact that Win10 isn’t registered yet on my system? It’s genuine Microsoft — but the poor colour performance is the main reason I haven’t registered yet.

***Modified Title from: Is Windows 10 limited to 256 colours while unregistered?***

Replies (11) 

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

Thank you for writing to Microsoft Community Forums.

We can imagine the difficulty you are facing. In order to get clarity, May I know the complete configuration, make and model of the system?

In the meantime, we would suggest you to try following methods and check of resolves the issue.

Method 1: Rollback the GPU driver .

Open Device Manager by searching for the same.

Expand Display adapter.

Right click on the driver and choose Properties.

Click on Driver tab.

Click on Roll back of the option is available and check.

Method 2: Uninstall the re-install the driver for graphics card .

Open Device Manager.

Expand Display adapter.

Right click on the driver and choose Uninstall driver.

Make sure to check the box behind Delete the driver software for this device.

Then restart the computer to complete the process.

Power on the system.

Go to Start > Settings > Update & security and click on Check for updates.

Check if the issue persists.

If yes, try installing from the manufacturer website, AMD driver Support and check.

2 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Thanks, Manjunath. The machine itself is an Apple Mac Pro which I’ve configured to dual boot using Apple’s ‘Boot Camp’ utility. It’s quite a high-spec computer with a 10-core Intel Xeon E5-2690 CPU (3.0 GHz). It also has dual AMD FirePro D300 GPUs. I could elaborate on the spec — but.

Over the weekend I’ve checked with some other Win10 users and this seems to be a very common problem — in fact AFAICT, concerns about the colour accuracy in Win10 are definitely delaying some users from purchasing it (including me. )

Before I start rolling back drivers etc, would you mind checking this for me an any Win10 machine? You just need to right-click on the desktop and then choose ‘Display settings’. Then scroll down a bit and click the option saying ‘Advanced display settings’ (not the one that says ‘Advanced scaling’). This will show you the ‘Settings’ window that I displayed above. Up to now, every single person I’ve spoken to has reported it showing a colour depth of just 8-bits (i.e. just 256 colours) and there seems to be no way to set it higher. 🙁

7 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

Windows 10 Neovim terminal doesn’t properly display 256 colors #9937

Comments

moshen commented Apr 25, 2019

nvim —version : Vim (version: ) behaves differently? Doesn’t have the :terminal functionality Operating system/version: Windows 10 Terminal name/version: Powershell $TERM : N/A ?

Steps to reproduce using nvim -u NORC

Actual behaviour

Also broken inside neovim-qt:

Expected behaviour

Using the WSL terminal and nvim inside WSL, this appears to work properly:

The text was updated successfully, but these errors were encountered:

justinmk commented Apr 27, 2019 •

Try the development version (0.4.0). The Releases page has pre-built archives for Linux/Windows/macOS.

Using the WSL terminal and nvim inside WSL, this appears to work properly:

So it works in some terminals and not others?

Nvim 0.4.0 supports more TERM values, see :help $TERM and try the various Windows values mentioned there.

moshen commented Apr 27, 2019 •

@justinmk No, I meant using the WSL terminal (A Console Window Host? Process looks the same as a cmd window and I don’t know that much about it) with the linux version of neovim running within WSL, 256 colors appear properly within the neovim :terminal .

When running the windows version of neovim, regardless of the terminal emulator, the neovim :terminal does not show 256 colors properly.

I just tried 0.4.0 and I get the exact same result.

justinmk commented Apr 27, 2019 •

@moshen The last screenshot shows 256 colors working in a :terminal , doesn’t it?

And which $TERM values did you try with 0.4.0? What does :echo &term show in each case?

moshen commented Apr 27, 2019

@justinmk The last screenshot is the example of the linux version of neovim running within wsl. I’ve been attempting to use that (but that setup has unrelated issues). Running the windows version doesn’t appear to work as expected.

:echo &term for various setups:

• nvim-qt
  • nvim
• nvim in powershell
  • builtin_vtpcon
• nvim in powershell in Fluent Terminal
  • builtin_xterm

When I change $TERM to something like xterm-256color in powershell, it appears to be set correctly in neovim (shows as builtin_xterm ).

All these result in the same thing.

justinmk commented Apr 27, 2019 •

see #9937 (comment)
see :help $TERM . Try the recommended Windows TERM values mentioned there.

justinmk commented Apr 27, 2019 •

Actually if term=builtin_vtpcon doesn’t show improvement then that settles it.

Maybe try the artifact from #9094 . If that doesn’t work then this is out of scope.

moshen commented Apr 27, 2019

Reviewed the $TERM list again and yes, vtpcon seems like it is appropriately set. Also when I load my init the 256 colorscheme seems to work. It is just colors within :terminal seem to be stuck in a 16 color mode.

erw7 commented Apr 28, 2019

This is limitation with winpty . As discussed in rprichard/winpty#152, we need to make winpty correspond to ConPTY , or if ConPTY is available, we need to change neovim to use ConPTY instead of winpty .

support 256 color #345

Comments

melspectrum commented May 11, 2016

please have 256 color support. thanks!

The text was updated successfully, but these errors were encountered:

zadjii-msft commented May 11, 2016

Thanks for the suggestion! This is actually pretty high on my personal list of requests for the future, however, we weren’t able to fit it into the Anniversary Update, though I’d keep my eye out in the future for it.

A coming insider update should have support to at least take the 256-color ANSI sequences and the full RGB ANSI sequences and find the nearest color that’s in our 16-color table, and use that to render, which should at least enable applications which use those sequences to not be totally broken.

I’m gonna close this as a dupe of #76, which has more discussion on the subject.

musm commented Jul 15, 2016 •

Could we get this reopened as #76 was closed since it was decided that the scope there was not 256 color support but just properly mapping 8-bit colors to the 256-bit range.

benhillis commented Jul 15, 2016

be5invis commented Jul 15, 2016

It is hard, almost impossible.
Conhost uses a fixed 32-bit-per-cell layout (16 bits for properties and 16 bits for character code), which is a derivative of VGA text mode (yes, the DOS-era video memory layout, 8 bits for properties and 8 bits for color). Modifying it will definitely break compatibility, unless MS want to implement a completely different console API set (and provide a compatibility layer for existing console apps).

musm commented Jul 15, 2016 •

Thanks @be5invis. It’s 2016, breaking compatibility with DOS I don’t think will in anyway affect anyone using windows 10, maybe a dozen people. It seems more logical to introduce a new fresh and modern console API that can be used for the next decade and retain the old conhost for legacy purposes.

Certainly, this wouldn’t be the first time compatibility has been broken and trying to maintain backwards compatibility for something that old is impressive. I like what they did with IE; tons of stuff depended on IE, but they figured a way around it and introduced Edge, by keeping IE installed but for legacy support.

Considering the large number of devs that use the terminal on a daily basis (esp. linux devs to are married to the terminal), i think this would benefit more people than it would affect. Bash on windows is wonderful, but it’s missing some polish and I think this would go a long way.

be5invis commented Jul 15, 2016 •

@musm However, I am talking about NT console API, which is the basis of almost all Windows console applications and many of them are important basic industrial infrastructure, controlling important things like nuclear power plants.
The only possible solution is to create a new console API interface and a bug-to-bug compatibility layer.

musm commented Jul 30, 2016

I’m going to ref #417 as @Maximus5 suggested the fix
«@zadjii-msft This issue is not actually forces msft to implement truecolor in conhost. In fact, and instead, topic starter asked you to bypass ANSI to ConEmu, which already supports true-color in console.
Current implementation of console output in WSL prohibits ConEmu from processing any ANSI written by linux applications. That tight integration with kernel(?) is rather bad.
I believe, the issue have to be reopened, ConEmu doesn’t limit user to 16-colors palette. And proposed approximation would look awful.»

be5invis commented Jul 30, 2016

@musm @benhillis @zadjii-msft
What if users do not have installed ConEmu?
The true problem is that CONHOST already used all bits of the console buffer. And programs can directly modify it via C/C++ code.
A solution may be to provide another completely different console API (stream-based) and provide a compatibility layer to the existing one (blitting the buffer at 60fps?). Maybe you MS guys should have a serious talk with OSG.

musm commented Jul 30, 2016 •

The suggestions is a hacky one I agree, but something hopefully sufficient for the group using conemu in the interim while MS cooks up (hopefully) a longer term fix for the future.
+1 for your idea of a new console API with a compatibility layer is far preferable of course

be5invis commented Jul 30, 2016

@musm
Hacky is necessary, because breaking existing console behavior may break important things like nuclear power plants. You definitely do not want that thing to happen.
If you want to connect your terminal to WSL, why do not just use SSH?

musm commented Jul 30, 2016

Could you clarify on how I would «If you want to connect your terminal to WSL, why do not just use SSH?»

be5invis commented Jul 30, 2016

SSH connect to localhost

musm commented Jul 30, 2016

Which problem would that solve? I mean SSHing from cmd/powershell from conemu to WSL, how does that fix things? Sorry I missed your point.

be5invis commented Jul 30, 2016

SSH with other tools like putty. That one should support full 256 colors

DanielGGordon commented Aug 4, 2016

I’m a bit confused here — I’m using Conemu — so is there a way for me to get 256 colors? Is there something I need to change? It looks like I still only have 16

musm commented Aug 4, 2016 •

No, not possible

DJviolin commented Aug 7, 2016 •

@be5invis Then why not fork cmd and start a separate console project for Windows 10, for example cmd256 ? Wouldn’t this be the best solution? Having full ANSI colors in Windows, but not touching the original cmd and finally vim will look as good as in xterm .

Or call it cmd-ansi or anything.

be5invis commented Aug 7, 2016

@DJviolin
As told by a MS employee from OSG, there was such a plan (simulates a graphics card — yeah, really), but they choose to use the native console, perhaps for the future lxss-win32 interop.

DJviolin commented Aug 7, 2016

MS people! Why not keep the lxss integration with cmd and having an alternate option to start bash.exe from cmd-ansi.exe (or any other windows commands)? Than you will have full color palette and lxss not tied to this console exclusively.

be5invis commented Aug 7, 2016

@DJviolin Manually start LXSS session and SSH to localhost?

cheshrkat commented Aug 9, 2016 •

Reading through this thread — philosophically, if lxss gets caught up in worries about older windows shells, it’s hard to understand the point of the project. Using the analogy from earlier. LXSS needs to be Edge vs. the IE8 of cmd/powershell.

Anyway to say what I actually came to say. +1 to fixing colours, it’s not a trivial thing when it prevents things like vim colour schemes (my use case was setting up https://github.com/crusoexia/vim-monokai); and my usual PS1 didn’t work because colours just disappeared. Way too easy to think of something like this as a nice-to-have, but in reality if LXSS doesn’t replicate the basics of using bash on other platforms it’s going to struggle to gain traction (and I really want it to gain traction :)).

DJviolin commented Aug 9, 2016

We talking about a thing that already works in ConEmu with injection. None of us wants to change the cmd ‘s default behaviour, we would be happy with an alternative console as well. Honestly, defining custom fonts, set font antialiasing, having 256 colors can be a deal breaker for many developers. We want VIM in it’s full glory, inside the console, not in a heavy GUI application. Plus scrolling through a source file without any popping artifacts fast (like what VIM suffered in ConEmu).

cowwoc commented Aug 13, 2016

Consider removing the duplicate tag, since this issue is no longer duplicate to #76.

jquick commented Aug 20, 2016 •

+1, ive had to resort to sshing into localhost with putty/mobaxterm to get support.

zadjii-msft commented Aug 24, 2016

Woah woah woah, boy did this discussion get out of hand.
First off, a bit of a clarification, because this happens in every console issue thread and unfortunately it’s not clearly explained anywhere as far as I know:
cmd.exe is different from conhost.exe .
cmd is a shell, much like bash , zsh , fish , or powershell .
conhost is the console window itself, like xterm or Terminal . All the shells above run within the conhost window, which displays the stdout and handles the stdin for your shell.

Now, conhost, is the place where the 16 color cap exists — the way the text is stored, it’s only possible to keep 16 colors on any character. Fixing that is a fairly sizable amount of work, and one that we’re definitely trying to work on. If it comes, it’s going to be via the escape sequences mechanism already in place in conhost, not via extending/changing the console API.

I am going to de-dupe this, because #76 was solved by supporting the true RGB color sequences by matching to the nearest color in Win10 AU, but true RGB color support isn’t quite there yet.

oblitum commented Oct 5, 2016 •

I think if I come back to windows I’m instead just gonna try some of these new distros for WSL that started to pop out + X, there’s an Arch variant already, rolling releases FTW 🙂

zadjii-msft commented Oct 5, 2016

@StoneCypher That’s correct. There’s no out-of-band release process for conhost unfortunately. The only way to get an update is with an OS update.

DJviolin commented Oct 5, 2016

@oblitum Do you have a source for this? If it’s possible Debian would be really great to use in WSL.

oblitum commented Oct 5, 2016

@DJviolin updated my comment.

oblitum commented Oct 5, 2016 •

@DJviolin I’ve seen a lot of stuff these days about slackware/arch etc, with X apps etcs, some weird stuff, maybe there’s something about Debian on the web, I don’t recall whether I’ve seen something about that or not.

bitcrazed commented Oct 6, 2016

@oblitum Re. alt distro’s: Note that they’re unsupported at this time, but do feel free to give them a try: We don’t do anything to prevent them from working; we’re just focusing all our effort on delivering as solid an experience as possible on Ubuntu at this time.