You are not logged in.
Yes. You're right. The developer making the kernel changes also has a github project for xf86-video-gma500, but he hasn't made any changes to it for 9 months, and obviously it has never been released - it's a fork of the modesetting driver and its comments only mention the initial creation, so it's not something that's viable.
It does concern me that Arch appears to jumping over a number of systemd version releases, ignoring most of the interim patches. I'm currently seeing that systemd-208-4 has been removed from the staging repository, and has in fact disappeared entirely. In its place is version 208-9 which is in the testing repository with only 1 or 2 more of the patches than they're currently using for systemd-208-3. Meanwhile, other distros, like Fedora, have well over a hundred patches in place by 208-7. Why is Arch ignoring all these bug fixes, including the FPDT zero-length read patch? The FPDT zero-length read patch fixes the well-known hanging-boot issue and was supposed to be applied to systemd starting with 208-6.
Offline
This is the same version of systemd (208). The last number is the pkgrel, which is just bumped anytime the packager makes a change. In the case of systemd, since we are awaiting the finalization of a number of features before 209 can be released, the Arch devs are simply backporting what they deem to be important fixes and repackaging.
Offline
I'm well aware of how it works (although bumping 208-3 to 208-9 is a little bizarre - what happened to pkgrels 4-8). The main point I was making is that the fpdt zero-length read fix should be considered an important addition since 1) the patch is available, and 2) not having that patch applied causes a good number of atom-based systems to hang at the start of boot-up, basically making the OS non-functional. Atom-based systems are not exactly on the fringe anymore. Without this, users would have to apply the patch to the source themselves then re-incorporate the modified version back into the installation image. That's not really a workable solution for most users.
The bug: https://bugzilla.redhat.com/show_bug.cgi?id=1027478
The patch: http://cgit.freedesktop.org/systemd/sys … 0035d4743a
Last edited by jghodd (2014-01-07 00:21:40)
Offline
So I think if you wish to have this patch included (and it seems like a very reasonable request), the issue should be taken up on the bug tracker where the right people will see it.
As far as where the other pkgrels go, they are there, but not every single pkgrel makes it to the repo. If a dev packages something and realizes that it is wonky, he can fix it and push a new pkgrel, all without ever having actually put it in any of the available repos. See the svntogit for all the packages and their progression.
Offline
Ok. Posted it on bugtracker and it looks like they're going to drop 208-9 and add it to 208-10. Thanks for the advice.
[Edit: the patch has already been committed for the next build.]
Last edited by jghodd (2014-01-07 06:51:27)
Offline
I saw that, and it has already been pushed to [testing]. Nice work jghodd.
Offline
Those waiting for the fpdt zero-length-read patch in an official release need wait no longer - systemd-208-10 has now been released with the patch included.
firekage - this should fix your systemd boot issue.
Cheers.
Offline
Does anyone have a clear picture of what is happening concerning support for these chips?
AFAIK, the only place, where something is happening is the kernel (gma550_gfx driver). Is any work done in the X server?
Also: Is it possible right now to achieve smooth playback of 720p h264 mkv? If yes, what (in terms of drivers, optimisations nad such) should I be looking at to achieve it?
Offline
Yes, there is work on an X driver that will provide 2d acceleration. Who knows when it'll be released though.
Smooth video playback... depends on if the X driver will provide a textured video Xv backend. Without the X driver you're limited to software scaling. mplayer/mpv provide control over what kind of scaling swscale should use (check the manpages), but I doubt any of them are fast enough for 720p video. On a beefy desktop CPU sure, but not on the crappy Atom.
Offline
but I doubt any of them are fast enough for 720p video. On a beefy desktop CPU sure, but not on the crappy Atom.
You are wrong. Atom is capable of doing that. On Windows it works very good, on linux...well, depends (N2600 could handle it with good driver, other Atoms with only one core or without hardware playback, like N570 won't do the job even with 2 cores).
Offline
(N2600 could handle it with good driver, other Atoms with only one core or without hardware playback, like N570 won't do the job even with 2 cores).
The thing is, that i have successfully watched 720p h264 mkv's on an acer aspire one a150 (atom N270 with intel GMA945 IIRC) - it wasn't totally smooth, but it "stuttered" only occasionally.
I have tried many different combinations of mplayer settings and i'm stumped: none seem to work as expected. Setting number of cores for processing doesn't seem to change anything, vo's x11, gl and gl(fast) desynchronize video and audio. Same thing for any working gl output. The only vo, that showed some promise was sdl - but video didn't scale to visible area in smplayer. Other outputs do not work at all - gray visible area. I will be posting screens later today CET - I've left the netbook at home.
Last edited by pordzio (2014-02-12 08:43:49)
Offline
Gusar wrote:but I doubt any of them are fast enough for 720p video. On a beefy desktop CPU sure, but not on the crappy Atom.
You are wrong. Atom is capable of doing that. On Windows it works very good
On Windows you'll have hardware scaling and colorspace conversion. In the part you quoted, I was talking about *software* scaling. The Atom can barely decode 720p video, add software scaling to that and the CPU becomes overwhelmed. That's why the need for an X driver that provides an Xv implementation (Xv = hardware scaling).
@pordzio: I have an Acer Aspire One A110 (Atom N270, GMA950 graphics). Using --vo=xv with mpv, 720p playback is possible provided that the bitrate of the video isn't too high. The "scene" produces 720p videos with an average bitrate of 3Mbps, the Atom N270 can handle that. The problem is at bitrate spikes (complex parts of the video where the bitrate goes much higher than 3Mbps), there the Atom will choke. No way around that, it's simply a crappy processor. The CedarView Atoms are probably a bit better than the N270, but not much.
Last edited by Gusar (2014-02-12 12:18:29)
Offline
hi,
i have a mini-itx with CPU Intel D2550 and GPU Intel 3600:
$ lspci|grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 0b)
the official Intel drivers for GPU are out-of-date (2012):
http://downloadcenter.intel.com/Detail_ … ldID=21938
i have tried to compile the source but it says errors:
$ sh autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:9: installing './compile'
configure.ac:9: installing './config.guess'
configure.ac:9: installing './config.sub'
configure.ac:4: installing './install-sh'
configure.ac:4: installing './missing'
Makefile.am: installing './INSTALL'
src/Makefile.am: installing './depcomp'
autoreconf: Leaving directory `.'
configure: WARNING: unrecognized options: --enable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop
checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libdrm... yes
checking for ANSI C header files... (cached) yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for library containing pthread_cond_init... none required
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating libwsbm.pc
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --enable-maintainer-mode
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop
checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libdrm... yes
checking for ANSI C header files... (cached) yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for library containing pthread_cond_init... none required
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating libwsbm.pc
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
$ make
make all-recursive
make[1]: ingresso nella directory "/tmp/cdv-gfx-drivers-1.0.3_bee/src/cedarview-libwsbm-1.1.0"
Making all in src
make[2]: ingresso nella directory "/tmp/cdv-gfx-drivers-1.0.3_bee/src/cedarview-libwsbm-1.1.0/src"
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libdrm -Wall -g -O2 -MT libwsbm_la-wsbm_fencemgr.lo -MD -MP -MF .deps/libwsbm_la-wsbm_fencemgr.Tpo -c -o libwsbm_la-wsbm_fencemgr.lo `test -f 'wsbm_fencemgr.c' || echo './'`wsbm_fencemgr.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libdrm -Wall -g -O2 -MT libwsbm_la-wsbm_fencemgr.lo -MD -MP -MF .deps/libwsbm_la-wsbm_fencemgr.Tpo -c wsbm_fencemgr.c -fPIC -DPIC -o .libs/libwsbm_la-wsbm_fencemgr.o
wsbm_fencemgr.c:41:32: fatal error: ttm/ttm_fence_user.h: File o directory non esistente
#include <ttm/ttm_fence_user.h>
^
compilation terminated.
make[2]: *** [Makefile:464: libwsbm_la-wsbm_fencemgr.lo] Error 1
make[2]: uscita dalla directory "/tmp/cdv-gfx-drivers-1.0.3_bee/src/cedarview-libwsbm-1.1.0/src"
make[1]: *** [Makefile:452: all-recursive] Error 1
make[1]: uscita dalla directory "/tmp/cdv-gfx-drivers-1.0.3_bee/src/cedarview-libwsbm-1.1.0"
make: *** [Makefile:361: all] Error 2
how can i solve? my pc is slow without accelerated driver :-(
Last edited by quellen (2016-09-30 19:23:48)
sorry for my bad english
Offline
@quellen: you are, unfortunately, out of luck. The Intel driver is not compatible with any kernel from the past 4 years, and is also incompatible with xorg. Currently, the only driver available is the gma500 driver that comes with the kernel. It does not provide acceleration. One of the Linux graphics developers started an xf86-video-gma500 xorg driver a few years back, but discovered that gpu rendering on the gma3600 was slower than cpu rendering and he stopped all development - it is currently incomplete (you can find it by googling xf86-video-gma500 if you want to look at it).
Despite a huge number of user requests to Intel for a better, more up-to-date driver for this graphics hardware, Intel has, for all intents and purposes, abandoned all support for the gma3600. The best I've ever been able to achieve is acceptable speed using a combination of a customised version of 915resolution, v86d and the gma500 kernel driver. But that only gets you acceptable 2D graphics. It's not fast, but for the usual desktop activities, it's fast enough. You can even stream standard-res video and get acceptable speed.
Cheers
Offline
Thanks for bad news, jghodd. :-(
i have tried to compile "xf86-video-gma500" from GIT but it says fatal error (maybe the source is too old):
$ make
make all-recursive
make[1]: Entering directory '/tmp/xf86-video-gma500-master'
Making all in src
make[2]: Entering directory '/tmp/xf86-video-gma500-master/src'
Making all in uxa
make[3]: Entering directory '/tmp/xf86-video-gma500-master/src/uxa'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/tmp/xf86-video-gma500-master/src/uxa'
make[3]: Entering directory '/tmp/xf86-video-gma500-master/src'
CC gma_driver.lo
In file included from drmmode_display.h:34:0,
from gma_driver.h:35,
from gma_driver.c:63:
libgma.h:4:30: fatal error: uapi/drm/gma_drm.h: No such file or directory
#include <uapi/drm/gma_drm.h>
^
compilation terminated.
make[3]: *** [Makefile:547: gma_driver.lo] Error 1
make[3]: Leaving directory '/tmp/xf86-video-gma500-master/src'
make[2]: *** [Makefile:566: all-recursive] Error 1
make[2]: Leaving directory '/tmp/xf86-video-gma500-master/src'
make[1]: *** [Makefile:450: all-recursive] Error 1
make[1]: Leaving directory '/tmp/xf86-video-gma500-master'
make: *** [Makefile:382: all] Error 2
The best I've ever been able to achieve is acceptable speed using a combination of a customised version of 915resolution, v86d and the gma500 kernel driver.
i have installed 915resolution and v86d from AUR. now what should i do?
i have followed wiki of Uvesafb but i can't install 915resolution-static:
$ sudo pacman -U 915resolution-static-0.5.3-9-i686.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...
Packages (1) 915resolution-static-0.5.3-9
Total Installed Size: 0.65 MiB
:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring [######################] 100%
(1/1) checking package integrity [######################] 100%
(1/1) loading package files [######################] 100%
(1/1) checking for file conflicts [######################] 100%
error: failed to commit transaction (conflicting files)
915resolution-static: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.
p.s.
glxinfo says that i have 3D acceleration:
$ glxinfo | grep -i render
direct rendering: Yes
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_packed_depth_stencil,
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
$ lsmod|grep -i gma
gma500_gfx 163840 2
drm_kms_helper 110592 1 gma500_gfx
drm 249856 4 drm_kms_helper,gma500_gfx
i2c_algo_bit 16384 1 gma500_gfx
video 32768 1 gma500_gfx
$ pacman -Q|grep xf86-video
xf86-video-fbdev 0.4.4-5
xf86-video-intel 1:2.99.917+708+g8f33f80-1
xf86-video-vesa 2.3.4-2
Last edited by quellen (2016-10-01 11:07:40)
sorry for my bad english
Offline
llvmpipe is a software acceleration rendering method, it's better then nothing but most people don't think of it is as being 3D accelerated.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
you need the modified version of 915resolution - https://sourceforge.net/projects/bluest … pkg.tar.xz
that assumes you want the 64-bit build. for the 32-bit build modify the url replacing all occurrences of x86_64 with i686.
for instructions, go here - http://bluestarlinux.sourceforge.net/in … ;article=9
cheers
Last edited by jghodd (2016-10-01 16:31:49)
Offline
Why do you need 915resolution? Doesn't the kernel gma500_gfx driver provide proper resolution?
Offline
current versions of the kernel still do not properly set up the gma3600 hardware. since later versions of 4.6 you can boot without any special modifications, but a number of different graphics apps will tear down your screen in no time. the 915resolution+v86d setup stabilises the setup. i know this because i have pretty much the same hardware setup as yours and tested a distro build without 915resolution+v86d when i noted a recent fix in the driver that was supposed to resolve the issue - it worked to boot up and start the graphics environment, but the first app i started up that i maximised to full screen completely destroyed the graphics setup. i had to back out my changes and restore the 915resolution+v86d setup. keep in mind that this is not an either/or setup. you will still be using the gma500 driver when using the 915resolution+v86d setup. it just stabilises your graphics environment.
Offline
ok, i have installed v96d+915resolution, add it to hook of mkinitcpio and reboot, but during systemd boot, it says:
Intel 800/900 Series VBIOS Hack : version 0.5.3
Intel chipset detected. However, 915resolution was unable to determine the chipset type.
Chipset Id: bf38086
Please report this problem to stomljen@yahoo.com
why? i'm totally out of luck?
(i have a 32-bit system)
Last edited by quellen (2016-10-01 17:47:09)
sorry for my bad english
Offline
i added your chipset id - https://sourceforge.net/projects/bluest … pkg.tar.xz
to clarify what 915resolution does, it modifies your VBIOS, setting up your resolution. without it, X goes bananas when it performs an operation that requires reading your resolution from the VBIOS. this is a hardware bug - 915 resolution is the workaround.
Last edited by jghodd (2016-10-01 18:38:33)
Offline
i added your chipset id - https://sourceforge.net/projects/bluest … pkg.tar.xz
thank you!
now it works, but the system doesn't seem faster, it's the same as before.
$ sudo 915resolution -l
Intel 800/900 Series VBIOS Hack : version 0.5.3
Chipset: 3600GM
BIOS: TYPE 1
Mode Table Offset: $C0000 + $268
Mode Table Entries: 36
Mode 30 : 640x480, 8 bits/pixel
Mode 32 : 800x600, 8 bits/pixel
Mode 34 : 1024x768, 8 bits/pixel
Mode 38 : 1280x1024, 8 bits/pixel
Mode 3a : 1600x1200, 8 bits/pixel
Mode 3c : 1920x1440, 8 bits/pixel
Mode 41 : 640x480, 16 bits/pixel
Mode 43 : 800x600, 16 bits/pixel
Mode 45 : 1024x768, 16 bits/pixel
Mode 49 : 1280x1024, 16 bits/pixel
Mode 4b : 1600x1200, 16 bits/pixel
Mode 4d : 1920x1440, 16 bits/pixel
Mode 50 : 640x480, 32 bits/pixel
Mode 52 : 800x600, 32 bits/pixel
Mode 54 : 1024x768, 32 bits/pixel
Mode 58 : 1280x1024, 32 bits/pixel
Mode 5a : 1600x1200, 32 bits/pixel
Mode 5c : 1920x1440, 32 bits/pixel
$ cat /lib/initcpio/hooks/915resolution
run_hook ()
{
msg -n ":: Patching the VBIOS..."
/usr/sbin/915resolution 54 1024 768
msg "done."
}
(my old 4:3 TV support only 1024x768)
Last edited by quellen (2016-10-01 19:32:51)
sorry for my bad english
Offline
yeah, but it's stable, and for most things, it's acceptable. the gma3600 was the one and only time that Intel outsourced the design and manufacturing of graphics hardware - to PVR. it made the chipset cheaper but the graphics was a disaster. they refuse to offer any support and apparently PVR won't release an open source driver - and PVR doesn't provide a proprietary linux driver. Intel made one attempt back in 2011/12, but since then they've abandoned the gma3600. the gma500_gfx driver is an open source driver, developed as a response to Intel's abandonment of the hardware, that gets very little attention these days. sometimes they'll tweak it to make it fit in with changes to other parts of drm, but no upgrades. you're stuck with what you have. it's a shame because the atom cpus released as part of these chipsets are quite decent in terms of performance.
all i can suggest is to use what you have now until you can get yourself something else.
cheers
Last edited by jghodd (2016-10-01 19:45:54)
Offline
it's too slow: for example zsnes runs in 35/60 fps with 1024x768 fullscreen. it's too little for a GPU with 630MHz.
btw, i'm not sure if i have the intel 3650, notebookcheck says so:
http://www.notebookcheck.net/Intel-Atom … 582.0.html
i have this motherboard:
http://www.asrock.com/mb/Intel/AD2550B-ITX/index.it.asp
sorry for my bad english
Offline
The GPU isn't involved at all. That's the problem. All the rendering you see is done in software, on the CPU. There is no hardware rendering for the GMA3600/3650. Configure zsnes to use a mode that doesn't use OpenGL (the ones with out an O next to them, as the instructions say), maybe those will run fast enough, but they probably won't be pretty.
And consider investing in a new machine, one with an Intel GPU. ITX boards have components usually branded with Celeron and not Atom, there's the Celeron J1800/J1900 (Baytrail, gen7 GPU), Celeron N3050/N3150 (Braswell, gen8 GPU) and Celeron J3060/J3160 (also Braswell).
Offline