Mesa 10.4.2 is available for testing

[Chih-Wei Huang]

Hi all,
I've pushed the new mesa porting which based on mesa 10.4.2
into the kitkat-x86 branch. Please sync, build and test it.

The i915 classical driver issue has been fixed.
Tested OK on EeePC 1000 (Atom N270),
WeTab (Atom N450 Pineview).

The i965 classical driver has been tested OK on
ASUS U45J (Ironlake),
UX31A (IvyBridge), T300LA (Haswell),
T100 (Baytrail).

Especially thanks to the nice work of Paulo Sergio
and Mauro Rossi so we can make the good progress.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[pstglia]

Thanks Chih-Wei. Without your help, we couldn't do that.

syncing now

[Mauro Rossi]

Hey Paulo,

speak for yourself,
I could have done it...

.. in one or two years. :-)

I am looking at the sequence of commits and I am stunned, because I was stuck with Android.mk files for weeks, Chih-Wei solved a lot of issues in a few hours.
Thanks!

PS: I guess I should go back to "horse racing betting"...

[rbg]

isn't that why he gets the big $$$$$ - LOL

[Chih-Wei Huang]

What $$$$$? Did you mean money? LOL

To be honest, I didn't get big money by doing the project.
There are some ads revenue from the webpage,
but that's managed by others. I didn't share or
pay attention to it for years. I even can't receive donation
after Paypal denied my account two years ago,,,

What I got is probably acute liver failure... LOL
I went to bed after 5:00am in the moring
after push all changes for the new mesa porting...

Is there anyone going to donate me? :)
However I don't really need the money
unless you are going to donate millions of dollars. LOL
I prefer to get some newer devices so
I can make more testing (and get worse liver failure...)
I'm looking for newer hardware like Intel Cherrytrail,
Broadwell, AMD GCN (Radeonsi) or Nvidia devices.
Anyone can donate that?

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

[rbg]

Oh come on..........as I recall you work for Asus research....and they won't fund any of that stuff for you?????

I was at a much lower level than you when I worked in the industry for 35+ years, so low in fact

that I had the contacts with most of the reps.....if I needed the latest xyz chip...it was on my desk

within a week..........I needed it cause my boss needed some work done with it and there eyes light

up cause that's their job............supply the movers and shakers so you can get your stuff in on the next wave

of products................so

Hit up some of your underlings, tell them what you need and why.......I no longer have those kind

of contacts but somebody in these forums MUST have and can get what you need......

Worst case....send me your list(you have my email) and let's see what can be done...!!!

[Chih-Wei Huang]

You are so courteous. Thank you!

Indeed Paulo and you have done very great
pilot research and debugging for the topic.
Without that it's impossible for me to achieve the result today.
Actually I've planned to upgrade mesa for years
but didn't get real progress until your participation.

Anyway, I think we are ready to merge the nouveau porting
you've done previously. Please send me the patches.

Besides, I really hope most of the changes in our git repo
could be merged into the mesa upstream.
I also hope more Mesa developers could more pay attention
to the android porting so we can support more devices
and get update more easier in the future.
For example, except nouveau, I also look forward to
fixing the vmwgfx and radeonsi drivers for android-x86.
We need more help from Mesa developers, of course.

Emil, please suggest how to do that
if you got the message. Thanks a lot!

Regards,

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

[Chih-Wei Huang]

2015-01-24 11:29 GMT+08:00 rbg <rbg.hp...@gmail.com>:
> Oh come on..........as I recall you work for Asus research....and they won't
> fund any of that stuff for you?????

Didn't I say I do this project in my spare time?
The project is nothing to do with my job at Asus.
Previously I had chance to test android-x86 on our new NB.
But that has been changed since I left the NB department.
I have no chance to test any newer hardware at this moment.

Actually I should do better job for my company
and easier live by stopping spending time this project.
I can't let my boss know I'm doing the project
otherwise he will think I waste too much time
on this unless project and affect my KPI.
After Google denied the dual OS idea one year ago
nobody in my company dare to mention the idea running
android on PC or NB since he will probably be fired.

> I was at a much lower level than you when I worked in the industry for 35+
> years, so low in fact
> that I had the contacts with most of the reps.....if I needed the latest xyz
> chip...it was on my desk
> within a week..........I needed it cause my boss needed some work done with
> it and there eyes light
> up cause that's their job............supply the movers and shakers so you
> can get your stuff in on the next wave
> of products................so
>
> Hit up some of your underlings, tell them what you need and why.......I no
> longer have those kind
> of contacts but somebody in these forums MUST have and can get what you
> need......
>
> Worst case....send me your list(you have my email) and let's see what can be
> done...!!!

I just said. Any of the new hardware like Cherrytrail, Broadwell or AMD GCN...

[Rinaldo Jonathan]

Uhh ... you got real liver failure? or I just understand something wrongly?
If it is real, we hope you get well soon (i'm pretty sure that in some case, mr. Price also hope you to get well, because if something bad happened, he can't continue "the development" lol :P )

Also about your PayPal ... I think you should start accepting bitcoins.

[bk chaw]

Any test build for testing? Thanks

[Julichi Garcia]

Hi from Spain!, I tested two ISO by pstglia in my motherboard zotac mini-itx u series with intel atom and one of them work (20150111) and the other don't boot... (20150121)

In my system, 4.4 r1 boot fine (i must to create pointercal file to do touchscreen calibrate to work) and the 4.4 r2 can't boot (like 20150121 pstglia)

The pstglia ISO 20150111 run faster than anything!! and opengl info is recognised like noaveau and mesa driver!! Great work and very thanks!!

I only need now support for one of my two 3g huawei modem :) k3765 and em770w (the last much better because it have GPS functions...)

I,m trying to integrate it reading a Huawei PDF "Huawei ril integration guide for android" but I'm newbie and can't to rebuild my ramdisk.img to get the init.rc changes to work...

My english is poor and my knowledge is more poor than it... so I can rebuild a ramdisk.img with mkbootimg tool but .img don't work properly...the system fail boot and when I view the file in ubuntu, the icon is other than the original ramdisk.img so i think that the rebuild is bad...

Anyway, great work with graphic drivers and my regards now!!

[Mauro Rossi]

Hi Chih-wei,

here is the status of our investigation efforts in nouveau and radeonsi, reported for you and the developers.

Enabling nouveau at this stage, even if not perfect, is relatively safe and will help in debugging and refine drm_gralloc_nouveau


nouveau:

After being stuck for a lot of time with the introduction of tr1/unordered_set in mesa,
Paulo (thanks!) found a way to use gnustl prebuilt shared library module in a way that does not conflict with Android c++ ABIs
In order to install prebuilt  libgnustl_shared.so a minimal external/gnustl project and Android.mk was used.

I was puzzled when I saw that this way of using GNUSTL did not require to adjust c++ headers order like done libstlport.mk
NOTE: the include of libstlport.mk in gallium nouveau Android.mk had to be disabled

I suppose that the module could be installed without the dedicated project and putting the same mk script in some existing Android*.mk, but I think is just some refinement. 

I've seen that in new kernel config nvidiafb is disabled, so ready to go.

init.sh can be modified permanently to check nouveaufb and people having problems with that could still use Vesa mode.

drm_gralloc_nouveau requires some finalization because on 3D extensions we have some nasty freeze (GPU lock?)
One way to trigger the freeze almost systematically is running OpenGL ES 2.0 Demos and cycle through the demos
 https://play.google.com/store/apps/details?id=fi.harism.effects&hl=it

This should help to speed up debugging by the community because we know how to trigger the locks

Side-effects of enabling nouveau gallium in mesa: none observed
Current issues or gralloc: locks, occasional MMAPERR errors, some background artifacts, invisible mouse cursor on NV40 chipset family

git: for mesa gallium nouveau the most updated is pstglia's, for drm_gralloc we have pstglia and of course emil's (thanks!!) that need just a comment in one line with sw_indicator flag,

but here you can find also the latest tested commits to support multiarch build of drm_gralloc (to be evaluated).

https://github.com/maurossi/hardware_drm_gralloc/commits/android_x86_64

the only relevant commit in my mesa-mesa git is this one, but still draft, for your inspiration,
asm disabling is just a workaround, but some changes are ready like makefile conditions and relative modules paths.

https://github.com/maurossi/mesa-mesa/commit/8e2a25c60517e219fd8c65d99870195bd0895cca


radeonsi:

Radeonsi requires LLVM; on kitkat-x86 all attempts to build ended in some error due to LLVM function argument mismatch
I guess LLVM version incompatibility o wrong declaration of version in our Android.mk (and maybe we miss something that may be obvious...)

With lollipop-x86 the LLVM functions arguments mismatch seems disappeared, but we see some LLVM vs libstlport c++ conflict.
Here my guessed guess was that Clang and LLVM are both version 3.5 with LL, but I may be guessing wrong.

git: My last attempt with lollipop-x86 is here, but most of the credit goes to pstglia, I've done some porting/optimization from Makefile.am to Android.mk and I'm more the bug-hunter type.
I can anyway confirm that, with conditional makefile variables, these changes do not break nouveau.

https://github.com/maurossi/mesa-mesa/commit/3f6cf110915af235498e8463a6f053be796e39b9

NOTE: libelf sources have different paths in lollipop-x86 and kitkat-x86, and LLVM versions are also different

Mauro

[rbg]

UNOFFICIAL KitKat-x86 4.4-r2, Mesa10.4, 64bit 3.18 kernel TEST BUILD

--------------------------------------------------------------------------------------------------

********************************************************************

WARNING: If you want to give it a try, be advised that:

 - These changes may contain bugs that could DAMAGE your hardware and/or cause DATA LOSS.

 - The iso was simply tested for boot and a couple things checked...

 - The uefi_img is NOT tested at all...

Use it AT YOUR OWN RISK. YOU WERE ADVISED

********************************************************************

---- FOR TESTING PURPOSES ONLY, available here: ----

   https://drive.google.com/folderview?id=0B2evBKvIpdYkYWltaHNKMjV0MHM&usp=sharing

identify:

---------

what build your running: kk-x86-4.4-r2 with kernel 3.18-x64 (iso / uefi_img)

your system: dell xyz / asus xyz / etc.

issue: wifi / screen / boot / ext4 format / etc. 

provide logcat / dmesg / bugreport logs if possible....

don't know how...use the android-x86 forums and look it up,

many others have done it....

Help the developers help you....

[Mauro Rossi]

>>> commits to support multiarch build of drm_gralloc (to be evaluated).

Correction: hardware/drm_gralloc in lollipop-x86 already has multiarch support, I had not checked yet.
M.

[Ravid Maduni]

checked the img, with my Asus Vivobook S500CA i3

working

*touch-10 fingers

*wifi- browsing+downloading+sending

*battery

*usb device as sdcard

*power button

*volume fn buttons

*installer uefi

*hardware keyboard

*graphic- opengl es 2.0/3.0- according antutu test

*touchpad mouse

*wireless mouse

not working

*camera

*bluetooth

thats all what i checked

here some screenshots from the antutu test for make sure

now it's a big beast. it's run faster than ever

 יום שבת, 24 בינואר 2015 בשעה 20:58:26 UTC+2, מאת rbg:

[Ravid Maduni]

can you make an img with gapps please?

בתאריך יום שבת, 24 בינואר 2015 בשעה 20:58:26 UTC+2, מאת rbg:

[pstglia]

---- FOR TESTING PURPOSES ONLY, available here: ----

   https://drive.google.com/folderview?id=0B2evBKvIpdYkYWltaHNKMjV0MHM&usp=sharing

Hi Rbg,

Have you updated your entire android src tree (repo sync) or just Kernel/Mesa? I'm asking this because I have different results from my local build (repo synced yesterday + complete build) than the img you posted.

I've tested both imgs on the following hw:

1) Unbranded desktop with A10-5800K / Radeon 7660D IGP

your img: Cannot enter graphical mode. I have drm/ioctl errors "[drm:radeon_info_ioctl] *ERROR* copy_to_user radeon_info_ioctl:548" (see dmesg and logcat attached)

my img: Can enter graphical mode. Antutu crashes on 3D testing (dalvik is threating a Warning as a fatal exception). 

Tested another app ("Mussoumano" - An Unity/OpenGL game) and it worked without probs

2) NB Samsung 270E5G-XD1 (Core I5 Ivybridge)

your img: Boots correctly and everything I tested worked (Antutu complete test, camera, "Mussoumano", Browser)

my img: The same issue I had testing on A10 5800K (Antutu crashing on 3D test, "Mussoumano" worked)

Have you updated libdrm? If not, which version are you using?

Thanks!

[rbg]

I did a complete repo sync yesterday on kitkat-x86.....so assume I have the latest from git..

repo'd after Chih-Wei posted.....built last evening and added some builds today....

[rbg]

takes a bit longer for memory to kick in...LOL

I do remembet now that I was working on the mesa classic stuff you had posted, I was working it with lillipop...

then I saw the 10.4 to git message from Chih-Wei, switched my java version, rebooted and started on

the kitkat stuff....BUT FROM GIT...I noticed it was mesa 10.4.2 and libpciaccess was from a main source

and not the intel-ia stuff you had referenced.......

so from what you had posted in the classic thread - mesa is different and libpciacess is different!!

On Saturday, January 24, 2015 at 5:33:47 PM UTC-5, pstglia wrote:

[rbg]

just looked in git....drm may have been updated...

3 days ago

Maarten Lankhorst

configure.ac: bump version to 2.4.59 for release

[rbg]

back from dinner and time with wife....

got a chance to look at those logs....the difference maybe that I build with the 64 bit kernel and yours appears

to be the standard 32bit kernel............maybe the difference somewhere..!!??

I could/can through up standard 32 bit kernel build or not......or you could build with 64 bit kernel and

test again..

On Saturday, January 24, 2015 at 5:33:47 PM UTC-5, pstglia wrote:

[rbg]

MESAg10

[pstglia]

I remember Chih-Wei posted kitkat wasn't compatible with 64 bits kernel (due binder v7), just lollipop...

If I'm wrong, what is the procedure to build a 64 bits kernel on kitkat?

Thanks again!

[rbg]

now that you mention it.....I do recall that....just assumed from my readings that

it was because of user space applications....(does that mean android-ia doesn't really work as they have had 64 bit kernel only for a while!!??)

and old habits die hard...I've been using/building

with 64 bit kernels for at least a year or more on my distributed android stuff....no issues..anyway

it seems 32 bit kernels only on kitkat and previous versions...LOL

I've always just added the following to my BoardConfig.mk in kitkat/jb, then commented out for whatever I was testing/building:

TARGET_CPU_ABI := x86

+TARGET_CPU_VARIANT := x86_64

+TARGET_KERNEL_ARCH := x86_64

+#

+#make default x86 kernel

+#

i+feq ($(TARGET_CPU_VARIANT),)

+#TARGET_CPU_VARIANT := x86

+#TARGET_KERNEL_ARCH := x86

+endif

#TARGET_ARCH_VARIANT := x86-atom

[pstglia]

Hi from Spain!, I tested two ISO by pstglia in my motherboard zotac mini-itx u series with intel atom and one of them work (20150111) and the other don't boot... (20150121)

20150111 was compiled with nouveau (nvidia opensource driver) enabled. It is disabled on 20150121 img

I,m trying to integrate it reading a Huawei PDF "Huawei ril integration guide for android" but I'm newbie and can't to rebuild my ramdisk.img to get the init.rc changes to work...

Maybe you could try this:

https://github.com/rabeeh/android-imx6-kitkat/blob/master/platform/hardware/ril.git/0030-ENGR00238951-Enable-Huawei-EM770W-for-JB-4.2.patch

 

[rbg]

Hey Pailo,

have built uploaded the 32 bit kernel build for you....other two (MESAg10) will be uploaded

sometime tomorrow...or you can pull the files from the 64 bit builds...

building standard kitkat-x86, default is 32 bit kernel...

I didn't expect this to happen BUT:

it's interesting that when I generated the efi_img after building the iso_img that

it rebuilds with a 64 bit kernel..............

(64 bit kernel, 32 bit user space.....same as android-ia on 4.4 builds??!!)

doesn't happen when I build with a 64 bit kernel, because it's already 64 bit...FWIW

I believe that Chih-Wei had fixed the issue with 64 bit kernels and 32bit user space

on both kitkat and lollipop but anyway...just trying to get builds up and offload Chih-Wei, 

for people to test so you can get feed back and do your good work.....thanks again for all you 

and Mario and Chih-Wei's efforts!!

On Saturday, January 24, 2015 at 7:23:48 PM UTC-5, pstglia wrote:

[Greg McGee]

Dangerously asking a likely newb question:

When finishing a repo sync, It says:

Syncing work tree: 100% (353/353), done.  

external/drm/: discarding 2 commits

external/mesa/: discarding 55 commits

I ave not committed anything locally.

Am I actually getting all the changes, or missing something?

[Greg McGee]

Tonights build seems to work smooth as glass on my old Lenovo X200T, youtube looks great, etc.
On x86-64 kernel.

[Meerio]

Atom n450 gma3150:
working smooth, i haven't noticed any particulare drop or increase on the performances ( antutu has the same score of rc2)
Great step forward!

I've also a netbook with ion and n270, if someone wants to activate nouveau for me i'll test it. i'm trying to have a build system on my own , only i lack ram on a desktop pc, i'll try to virtualize ubuntu..( dual boot breaks my standby function on w8)

[pstglia]

have built uploaded the 32 bit kernel build for you....other two (MESAg10) will be uploaded

sometime tomorrow...or you can pull the files from the 64 bit builds...

building standard kitkat-x86, default is 32 bit kernel...

Thanks a lot rbg!

I've tested the 32 bits img on the same 2 targets + a third one

1) Unbranded desktop with A10-5800K / Radeon 7660D IGP

 - Can boot and reach graphical mode

 - Antutu performed all tests (including 3D) correctly (78857 pts)

 - "Mussoumano - Unity/OpenGL Game" works correctly and smooth

 - Internet browser works

 - Audio works

 - Candy Crush Soda worked

2) NB Samsung 270E5G-XD1 (Core I5 Ivybridge)

 - Can boot and reach graphical mode

 - Antutu performed all tests (including 3D) correctly (79065 pts)

 - "Mussoumano - Unity/OpenGL Game" works correctly and smooth

 - Internet browser works

 - Camera works

 - Volume buttons (Fn key) works

 - Candy Crush Soda worked

3) NB Samsung RV410 AD2 BR (Pentium dual core - T4500 - Intel GM45 )

 - Can boot and reach graphical mode

 - Antutu performed all tests (including 3D) correctly (35198 pts)

 - "Mussoumano - Unity/OpenGL Game" works correctly and smooth

 - Internet browser works

 - Camera works

 - Volume buttons (Fn key) works

 - Candy Crush Soda Crashes (appears to be a missing config/feature on 915)

I've attached some shots and dmesg/logcat for each system

Seems my building environment is causing the issue (Crashing Antutu / dalvik issue). Don't think my src is outdated. 

Maybe gcc version and libs (I'm using gcc 4.7.1 - yours is  4.8.2). 

Have changed a couple of things on my so recently (kernel version, mesa version, some libs, etc...). I'm using Slackware 14

Wherever... I'll check it out later

Thank you very much for providing the builds and info about 64 bits compiling! 

[rbg]

good...thanks for showing me there can be a difference....!!

you may want to update a few things on your build environment...just check minimums from here

     https://source.android.com/source/building.html

and Chih-Wei can comment on the 64bit, 32bit user space again for some of us who

are slow at understanding it....LIKE ME - LOL  just kidding...worked with the first

DEC Alpha(1st 64 bit CPU) back in early 1990...remember all of the s*it we needed to

go through to get up to speed and doing "real" work......so for me it's a re-education...

[Jocky Wilson]

I tested this with 3.18.2 kernel on my baytrail-t tablets. Youtube videos seem to be played with a too low framerate. After about 5 min testing the system freezes. I am running a live system from a 8GB pen drive.

Cheers,

JockyW

[pstglia]

Could test another hardware using 32 bits kernel img:

NB Asus 1015PE Seashell Series - Atom N550 dual core

- Can boot and reach graphical mode

 - Antutu performed all tests correctly (3D partially - lacks most of textures and runs at 1fps, but this is not a hw meant for 3D) (15559 pts)

 - "Mussoumano - Unity/OpenGL Game" works correctly, but very slow

 - Internet browser works

 - Camera works

 - Volume buttons (Fn key) works

Not a gaming hw for sure (even on other SO's). But can handle other basic tasks quite well.

[Nicola Pietragalla]

Somenone could give me a link to the most updated iso, if possibile with gapps, for 4.4 and latest tweaks for intel based gpu's? cause i have a small atom n330 based pc
on which i can test it, thank you very much far all your efforts!

[pstglia]

Somenone could give me a link to the most updated iso, if possibile with gapps, for 4.4 and latest tweaks for intel based gpu's? cause i have a small atom n330 based pc
on which i can test it, thank you very much far all your efforts!

rbg posted a link on this topic... 

[Nicola Pietragalla]

The "for testing purponse only"? i've read something like it was build in 64bit, that is high experimental if i've understanded well, i can test it too, but just wondering if exists a classical 32bit iso with latest mesa/driver optimized for intel...
(however i'm downloading it) 

[Nicola Pietragalla]

i'm a dumb*ss, excuse me, i've reached the link from rgb and i've founded a directory named 32kernel builds -_- so i can go on?

Il giorno domenica 25 gennaio 2015 19:52:23 UTC+1, pstglia ha scritto:

[pstglia]

i'm a dumb*ss, excuse me, i've reached the link from rgb and i've founded a directory named 32kernel builds -_- so i can go on?

No problem friend! Outside 32bits folder are 64 bits kernel imgs files. Those with "MESAg10" includes gapps. 

There's just 32 bits kernel imgs without gapps at this moment.

Give a try on both and post your results.

Regards,

Pstglia

[Mauro Rossi]

Hi,

Today I have checked the gallium nouveau build and the status of drm_gralloc.


Starting from simple things here are the few lines to enable EGL-Gallium accelerated nouveau:

https://github.com/maurossi/device_generic_x86/commit/fb14a453cb730b1e2eaaeb89c0ef2788bf80fd36


I have pushed to my github  the changes to fix errors in building gallium nouveau,  99.9% of the credit to pstglia solution.

https://github.com/maurossi/mesa/commit/8e10e0eca56f60340f3e18fd340e57e8506c32cd


Talking about drm_gralloc_nouveau.c, with current as-is "sw indicator love" commit, the screen becomes "white with random colored dots" - no rendering :-(
while commenting the SW_INDICATOR_FULLY_DISABLES_TILING define, I see a working GUI.

It was somehow expected behaviour, because I had already seen this, but I double checked by re-creating ISOs with and without the line and result is confirmed.
So the line need to be commented like in the following commit:

https://github.com/maurossi/hardware_drm_gralloc/commit/6cd32ee8259bc9618ad6b4528369131effe83f45



Here is the "fake gnust project" Android.mk, to show the makefile script that could go in an existing Android*.mk file, but which one?

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := libgnustl_shared
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES :=  ../../prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.8/libs/$(TARGET_ARCH)/libgnustl_shared.so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_SUFFIX := $(TARGET_SHLIB_SUFFIX)

include $(BUILD_PREBUILT)


Mauro

PS: did I mention that this was pstglia's Xmas gift to us?

[rbg]

thanks Paulo....

for others:

I have now separated the builds in their own folders so there should be no confusion...

When first built/posted I only use 64 bit kernels, but Pstglia has shown me the error in that...so 
now you can chose which works best for you....32 bit kernel, or 64 bit kernel with 32 bit user space

Original announcement should now read as follows:

UNOFFICIAL KitKat-x86 4.4-r2, Mesa10.4, with 3.18 Kernel TEST BUILD

-------------------------------------------------------------------------------------------------

---- FOR TESTING PURPOSES ONLY, available here: ----

   https://drive.google.com/folderview?id=0B2evBKvIpdYkYWltaHNKMjV0MHM&usp=sharing

the rest of the 32-bit builds should be up by tomorrow...

[Chih-Wei Huang]

2015-01-25 8:23 GMT+08:00 pstglia <pst...@gmail.com>:
> I remember Chih-Wei posted kitkat wasn't compatible with 64 bits kernel (due
> binder v7), just lollipop...

If I remember correctly, I have a post saying I have fixed
the 64-bit kernel 3.18 compatibility issue on kitkat-x86.
The fix is so easy that it's just a one line change.
The efi_img of 4.4-r2 release uses 64-bit kernel.

Besides, the old kernel 3.10 branch can be built to 64-bit
on kitkat-x86 long time ago. (patches by Intel)

> If I'm wrong, what is the procedure to build a 64 bits kernel on kitkat?

The efi_img will build with 64-bit kernel by default.
If you want to build 64-bit kernel on iso_img, say

time m -jX iso_img TARGET_KERNEL_ARCH=x86_64

[Carbon Jiao]

$ source build/envsetup.sh

$ lunch 5

$ LANG=en_US make -j4 efi_img | tee ./1.log

============================================

PLATFORM_VERSION_CODENAME=REL

PLATFORM_VERSION=4.4.4

TARGET_PRODUCT=android_x86

TARGET_BUILD_VARIANT=eng

TARGET_BUILD_TYPE=release

TARGET_BUILD_APPS=

TARGET_ARCH=x86

TARGET_ARCH_VARIANT=x86

TARGET_CPU_VARIANT=

HOST_ARCH=x86

HOST_OS=linux

HOST_OS_EXTRA=Linux-3.18.0-9-generic-x86_64-with-Ubuntu-14.04-trusty

HOST_BUILD_TYPE=release

BUILD_ID=KTU84Q

OUT_DIR=out

============================================

[rbg]

thank you for the explanation on 32 bit vs 64 bit again.......some of us(like me) are now slower!!

hope you had some good vacation time with your family and you enjoy the Android BootCamp.....

now could we get back to work on lollipop......JUST TEASING....

if you can't laugh at yourself.......!!!!!!!!!!!!

based on Paulo's and my conversation their maybe a "glitch" somewhere in drm when building

64 bit vs 32 bit with 4.4-r2 I feel.........!!!!!!!!!!

doesn't llvm/drm/mesa/etc. need to be all updated to newer versions on lollipop...???

based on your/google slides for lollipop changes????

[john gully]

Is there any chance of adding drivers to the 32bit image for the rtl8723bs WiFi as everything else works fine on the encore2 wt10 except no WiFi. I did find the drivers on github but have no idea how to use it.

Thanks

John

[Carbon Jiao]

you can extract the drivers to kernel/drivers/net/wireless, then the driver folder will be "kernel/drivers/net/wireless/rtl8723bs"

and add below line to kernel/drivers/net/wireless/Kbuild under line 279
source "drivers/net/wireless/rtl8723bs/Kconfig"

add below line to line 29 of drivers/net/wireless/rtl8723bs/Makefile

obj-$(CONFIG_RTL8723) += rtl8723bs/

Such as below diff:

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig

index dd02a41..fb7dc54 100644

--- a/drivers/net/wireless/Kconfig

+++ b/drivers/net/wireless/Kconfig

@@ -215,6 +215,8 @@ config USB_NET_RNDIS_WLAN

 

 source "drivers/net/wireless/rtl818x/Kconfig"

 

+source "drivers/net/wireless/rtl8723bs/Kconfig"

+

 config ADM8211

        tristate "ADMtek ADM8211 support"

        depends on MAC80211 && PCI

diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile

index 5db82da..24f23a7 100644

--- a/drivers/net/wireless/Makefile

+++ b/drivers/net/wireless/Makefile

@@ -24,6 +24,7 @@ obj-$(CONFIG_B43LEGACY)               += b43legacy/

 obj-$(CONFIG_ZD1211RW)         += zd1211rw/

 obj-$(CONFIG_RTL8180)          += rtl818x/

 obj-$(CONFIG_RTL8187)          += rtl818x/

+obj-$(CONFIG_RTL8723)          += rtl8723bs/

 obj-$(CONFIG_RTLWIFI)          += rtlwifi

Then add the corresponding  configuration into your config file. Then enjoy it...

[rbg]

Pstglia...

it's soup.....the other 32 bit files have been uploaded for testing............

[john gully]

Don't mean to be rude but that is all Chinese to me. Is there a more thorough step by step guide or an easier ,no brainer way to add it.

TIA

John

[Rinaldo Jonathan]

It is already step by step.
What you mean by "all chinese" ?

Take a note, the main developer is chinese. At least from their name.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[Mauro Rossi]

Hi John,

If you asked how to add the driver to kernel for compiling, the diff patch "script" seems complex at the beginning, but it's not that difficult:

 a/... and b/... are the AS-IS and TO-BE files

+ indicates a line to be added

- indicates a line to be removed

the entry "@@ -line_coordinate,number_of lines +line_coordinate, number_lines  @@ [something]" gives information about the coordinates in the file and about the AS-IS and TO-BE line_coordinate and number of lines changed and that they are near [something].

In this case, in the end, after having expanded the folder as explained, there are just two lines to be added to /drivers/net/wireless/Kconfig and one line to be added to /drivers/net/wireless/Makefile

NOTE: in a more general/complex case the patch command can do the changes for you

Regarding the kernel .config, there is information here: https://groups.google.com/forum/#!msg/android-x86/RX2qNkRJ0UI/xkDEt4OjHoEJ

M.

[rbg]

have seen many requesting this module.....BUT

would it not be best to include it first as an extra module as was done for the RTL8723AU module

initially....??? AND/OR add it into staging at least......!!!!!!!!! ???????

at least until it's fully tested and pushed to staging by the Linux Kernel developers!!

just a thought and IMO

[hashirt]

Hello. Just reporting back that two 32-bit iso images shared by rbg installed succesfully. It was the same old computer I reported installation error at previous thread.

Biostar g31m motherboard
Intel G33/G31 Express Chipset Family
Pentium 4 Dual Core 3.20 ghz
1 gb memory

Although at first boot (mesag10 image), right at language selection part, I remember a notification popup continuously reporting problem about "mapps" or "maps" or something similar. I can hopefully reproduce this if that's needed or it is not a known problem. Closing the popup real quick and continuing didnot cause an issue.
Also I'm experincing tear a bit on applications I installed to see how it is. Some of them crashed right away. I thought it could be my nearly dead machine. I will *try* to pinpoint the issues and give a more detailed feedback. I'm not that experienced with this stuff though.

[rbg]

yes the maps popup issue was my mistake....trying to hurry and when I realized it all

worked fine after dismissing it I just uploaded the build.....it has been addressed(hopefullt)

for any newer builds.......tearing on the apps maybe of interest to the developers though........

[john gully]

Yes assumed the same,not being racist what it means is i cant read ,understand chinese so i cant understand this either but iam going to see if i can give it a try tonight. I do appreciate all the help and effort from this site though.

Thanks

john

[Chih-Wei Huang]

2015-01-27 3:24 GMT+08:00 rbg <rbg.hp...@gmail.com>:
> have seen many requesting this module.....BUT
>
> would it not be best to include it first as an extra module as was done for
> the RTL8723AU module
> initially....??? AND/OR add it into staging at least......!!!!!!!!! ???????
>
> at least until it's fully tested and pushed to staging by the Linux Kernel
> developers!!

Sure.
If someone can confirm the driver works as expected,
I can add it to the codebase.

[rbg]

there are still issues being worked by lwfinger on the 3.19 kernel integration....

people here are testing it it seems....BUT in what 3-4 weeks it'll be in 3.19 staging...

[Carbon Jiao]

Compiled errors for 3.10.58...

/mnt/lollipop/lollipop_x86/kernel/drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_ddi_init':

/mnt/lollipop/lollipop_x86/kernel/drivers/gpu/drm/i915/intel_ddi.c:1538:18: error: 'struct intel_connector' has no member named 'hotplug_switch'

    hdmi_connector->hotplug_switch.name =

                  ^

/mnt/lollipop/lollipop_x86/kernel/drivers/gpu/drm/i915/intel_ddi.c:1540:23: error: 'struct intel_connector' has no member named 'hotplug_switch'

    if (!hdmi_connector->hotplug_switch.name) {

                       ^

make[6]: *** [drivers/gpu/drm/i915/intel_ddi.o] Error 1

make[5]: *** [drivers/gpu/drm/i915] Error 2

make[4]: *** [drivers/gpu/drm] Error 2

make[3]: *** [drivers/gpu] Error 2

make[3]: *** Waiting for unfinished jobs....

[john gully]

The WiFi driver works as some one already combined it into the latest kikat so I replaced some of his files including the kernel into this mesa one and it boots with WiFi working but the tablet locks up after awhile ,I think because of the mixture of mesa and the latest kikat that's for down load, if that makes sense.

Thanks

[Chih-Wei Huang]

Hi Mauro,
Thank you for the explanations.
The most difficult problem is currently
I don't have devices to test nouveau or radeonsi.
So I can only rely on you to test that.

2015-01-24 16:57 GMT+08:00 Mauro Rossi <issor...@gmail.com>:
> Hi Chih-wei,
>
> here is the status of our investigation efforts in nouveau and radeonsi,
> reported for you and the developers.
>
> Enabling nouveau at this stage, even if not perfect, is relatively safe and
> will help in debugging and refine drm_gralloc_nouveau
>
>
> nouveau:
>
> After being stuck for a lot of time with the introduction of
> tr1/unordered_set in mesa,
> Paulo (thanks!) found a way to use gnustl prebuilt shared library module in
> a way that does not conflict with Android c++ ABIs
> In order to install prebuilt libgnustl_shared.so a minimal external/gnustl
> project and Android.mk was used.

Instead of using Paulo's trick, I have worked out a patch
to use the unordered_set implementation in stlport (as attached).
Basically speaking, the stlport already has the unordered_set header,
but not in the tr1/ subdir (C++11 standard?).
However, trying to instantiate it with a user-defined type (e.g., ValueRef *)
causes a lot of strange errors. I can't understand why.
Probably a bug of stlport or g++ itself.
However, instantiating a built-in type is fine.

So the patch changes to use unordered_set<void *> and adds a wrapper
template class to convert the iterators to the expected user-defined type.
It builds fine now. However, as I said, I have no device to test now.
Please test it.

> I was puzzled when I saw that this way of using GNUSTL did not require to
> adjust c++ headers order like done libstlport.mk
> NOTE: the include of libstlport.mk in gallium nouveau Android.mk had to be
> disabled
>
> I suppose that the module could be installed without the dedicated project
> and putting the same mk script in some existing Android*.mk, but I think is
> just some refinement.
>
> I've seen that in new kernel config nvidiafb is disabled, so ready to go.
>
> init.sh can be modified permanently to check nouveaufb and people having
> problems with that could still use Vesa mode.

Please send me a patch or at least
give me the exact name of nouveau fb.


I'll check the other items below later.

> drm_gralloc_nouveau requires some finalization because on 3D extensions we
> have some nasty freeze (GPU lock?)
> One way to trigger the freeze almost systematically is running OpenGL ES 2.0
> Demos and cycle through the demos
> https://play.google.com/store/apps/details?id=fi.harism.effects&hl=it
>
> This should help to speed up debugging by the community because we know how
> to trigger the locks
>
> Side-effects of enabling nouveau gallium in mesa: none observed
> Current issues or gralloc: locks, occasional MMAPERR errors, some background
> artifacts, invisible mouse cursor on NV40 chipset family
>
> git: for mesa gallium nouveau the most updated is pstglia's, for drm_gralloc
> we have pstglia and of course emil's (thanks!!) that need just a comment in
> one line with sw_indicator flag,
>
> but here you can find also the latest tested commits to support multiarch
> build of drm_gralloc (to be evaluated).
>
> https://github.com/maurossi/hardware_drm_gralloc/commits/android_x86_64
>
> the only relevant commit in my mesa-mesa git is this one, but still draft,
> for your inspiration,
> asm disabling is just a workaround, but some changes are ready like makefile
> conditions and relative modules paths.
>
> https://github.com/maurossi/mesa-mesa/commit/8e2a25c60517e219fd8c65d99870195bd0895cca
>
>
> radeonsi:
>
> Radeonsi requires LLVM; on kitkat-x86 all attempts to build ended in some
> error due to LLVM function argument mismatch
> I guess LLVM version incompatibility o wrong declaration of version in our
> Android.mk (and maybe we miss something that may be obvious...)
>
> With lollipop-x86 the LLVM functions arguments mismatch seems disappeared,
> but we see some LLVM vs libstlport c++ conflict.
> Here my guessed guess was that Clang and LLVM are both version 3.5 with LL,
> but I may be guessing wrong.
>
> git: My last attempt with lollipop-x86 is here, but most of the credit goes
> to pstglia, I've done some porting/optimization from Makefile.am to
> Android.mk and I'm more the bug-hunter type.
> I can anyway confirm that, with conditional makefile variables, these
> changes do not break nouveau.
>
> https://github.com/maurossi/mesa-mesa/commit/3f6cf110915af235498e8463a6f053be796e39b9
>
> NOTE: libelf sources have different paths in lollipop-x86 and kitkat-x86,
> and LLVM versions are also different

[Jocky Wilson]

I can confirm kitkat with new mesa locks up after a few minutes on one of my baytrail tablets. At least it does on the voyo a1 mini when i use the 8723bs wifi driver. Not sure yet if it is because of the wifi driver or because of the new mesa. I will continue to test that.

[Luigi Capriotti]

I am experiencing lockups (32bit kernel), using a Thinkpad X61 (GMA950)

[Meerio]

If someone can give me a build with noveau i can test and report what needed!
My netbook is a compaq mini 311c, atom n270 and nvidia ion chipset , 2gb ram!

[Gabriel GOUGUET]

Hello,

I do not know if it can help for the problem of lockup but on the git.kernel.org site a commit for drm_intel was added 3 days ago

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9e4fc22a95b7512c6e540725093498025396ef5d

Merge tag 'drm-intel-fixes-2015-01-15' of git://anongit.freedesktop.org/drm-intel into drm-fixes

misc i915 fixes * tag 'drm-intel-fixes-2015-01-15' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES
drm/i915: Ban Haswell from using RCS flips
drm/i915: vlv: sanitize RPS interrupt mask during GPU idling
drm/i915: fix HW lockup due to missing RPS IRQ workaround on GEN6
drm/i915: gen9: fix RPS interrupt routing to CPU vs. GT

Best Regards

[rbg]

??? > lollipop_x86

the push was for the KitKat branch...
why are you building on lollipop..and not expecting failures!!!!!!!!!!!????????

[Chih-Wei Huang]

2015-01-25 14:59 GMT+08:00 Greg McGee <gjm...@gmail.com>:
> Dangerously asking a likely newb question:
>
> When finishing a repo sync, It says:
> Syncing work tree: 100% (353/353), done.
>
> external/drm/: discarding 2 commits
> external/mesa/: discarding 55 commits
>
> I ave not committed anything locally.
> Am I actually getting all the changes, or missing something?

The messages are normal since
the branch is rebased.

[Chih-Wei Huang]

Thank you for the good information.
I'll check if it's helpful to our problem.

[john gully]

Can you please upload your image if its efi so I can try it.

Thanks

John

On Tuesday, January 27, 2015 at 5:52:48 PM UTC+10:30, Jocky Wilson wrote:

[Jocky Wilson]

You can download it here: https://drive.google.com/file/d/0BwLKAtSVab_qTXc4azNTRWFLYTQ/view?usp=sharing

(android-x86-kitkat-rtl8723bs-kernel_3.18.2-mesa10.4.2.iso)

/JockyW

[Mauro Rossi]

Hi Chih-Wei,

I built and tested the latest patch to mesa and first impression on GTX560 is that mesa has the same level of functionality as per Paulo's libgnustl trick.

IMHO it would be nice to try to ask stlport mantainers to implement the support of the few missing templates, compared to other STLs,

in order that mesa source could not be impacted. In the end, STLport would be the first to benefit from the correction.

You can find in my post dated January, 25th the changes to enable nouveau experimental support in init.sh - kernel module name is nouveaufb - and the necessary change to drm_gralloc_nouveau.c to have proper rendering.

I could check some OpenGL apps (Gears, Rajawali, OpenGL ES 1.0 Demo) on AMD Phenom II with Nvidia GTX 560,

but result are not conclusive yet, because I need to check on Nvidia HW with Intel Cpus, where I don't have systematic crash of Basemark ES2 Taiji and 3DRating for OpenGL ES 2.0 (Antutu).

During weekend, at my hometown house, I'll perform more tests on different Nvidia HW, without the "AMD cpu variable".

Mauro

[Chih-Wei Huang]

2015-01-29 6:51 GMT+08:00 Mauro Rossi <issor...@gmail.com>:
> Hi Chih-Wei,
>
> I built and tested the latest patch to mesa and first impression on GTX560
> is that mesa has the same level of functionality as per Paulo's libgnustl
> trick.
>
> IMHO it would be nice to try to ask stlport mantainers to implement the
> support of the few missing templates, compared to other STLs,
> in order that mesa source could not be impacted. In the end, STLport would
> be the first to benefit from the correction.

No. I don't see there are missing templates (at least for this issue).
The issue is g++ just generates strange errors on using
the unordered_set template for a user-defined type.

To demo the errors easier, I wrote a small program t.cpp:

#ifdef __ANDROID__
#include <unordered_set>
#else
#include <tr1/unordered_set>
#endif

struct Instruction { };

main()
{
std::tr1::unordered_set<void *> v;
Instruction *p1=0;
v.insert(p1); // this is fine

std::tr1::unordered_set<Instruction *> s;
Instruction *p2=0;
s.insert(p2); // this generates an error with stlport
}

It builds fine by g++ with libstdc++

g++ t.cpp

However, it can't build with stlport:

g++ -nostdinc -Iexternal/stlport/stlport -Ibionic
-Ibionic/libc/include -Ibionic/libc/arch-x86/include
-Ibionic/libc/kernel/common -Ibionic/libc/kernel/common/linux
-Ibionic/libc/kernel/arch-x86 -Ibionic/libm/include
-Ibionic/libstdc++/include
-Iprebuilts/gcc/linux-x86/x86/i686-linux-android-4.7/lib/gcc/i686-linux-android/4.7/include
-D__ANDROID__ t.cpp

So I guess it's either a bug of g++ or stlport, or both.
Will try to ask in gcc or stlport list later.

Anyway, I think my patch could be merged into mesa upstream
since it just replaces several unordered_set instantiations
by one std::tr1::unordered_set<void *> so
it generates smaller object code size theoretically.

> You can find in my post dated January, 25th the changes to enable nouveau
> experimental support in init.sh - kernel module name is nouveaufb - and the
> necessary change to drm_gralloc_nouveau.c to have proper rendering.

OK, I'll push the other changes later.

BTW, I saw a warning on compiling gralloc_drm_nouveau.c:

hardware/drm_gralloc/gralloc_drm_nouveau.c:390:9: warning: missing
initializer [-Wmissing-field-initializers]
hardware/drm_gralloc/gralloc_drm_nouveau.c:390:9: warning: (near
initialization for 'nvc0_data.base') [-Wmissing-field-initializers]

Should we worry about it?
Shouldn't nvc0_data be initialized with some proper values?

[Chih-Wei Huang]

2015-01-29 13:39 GMT+08:00 Chih-Wei Huang <cwh...@android-x86.org>:
> 2015-01-29 6:51 GMT+08:00 Mauro Rossi <issor...@gmail.com>:
>> You can find in my post dated January, 25th the changes to enable nouveau
>> experimental support in init.sh - kernel module name is nouveaufb - and the
>> necessary change to drm_gralloc_nouveau.c to have proper rendering.
>
> OK, I'll push the other changes later.

I've pushed the necessary changes to
device/generic/x86/ and hardware/drm_gralloc/
in the kitkat-x86 branch.

Is there any other change we need to enable nouveau?

[Douglas Santillan A.]

Perhaps using boost libraries.

Or, using TR1 inclusions from the NDK:
- APP_STL := gnustl_static
- remove stlport_static references
- cpp flags -std c++0x

Code changes to
include <memory>

Or something like that.

[Chih-Wei Huang]

2015-01-29 15:05 GMT+08:00 Douglas Santillan A. <capri...@gmail.com>:
> Perhaps using boost libraries.

Too complex for this small issue.

> Or, using TR1 inclusions from the NDK:
> - APP_STL := gnustl_static

This is not an NDK build.

> - remove stlport_static references
> - cpp flags -std c++0x
>
> Code changes to
> include <memory>

Why?

> Or something like that.

Anyway, I worked out another patch to use gnustl_static directly
as attached. You may try if it works as expected.
(do not apply previous patch, just apply this one)

But I still prefer using stlport since it generates
smaller code size (differ about 40KB in my test).

[rbg]

UNOFFICIAL KitKat-x86 4.4-r2, Mesa10.4 TEST BUILDS

--------------------------------------------------

      ---- FOR TESTING PURPOSES ONLY----

********************************************************************

WARNING: If you want to give it a try, be advised that:

 - These changes may contain bugs that could DAMAGE your hardware and/or cause DATA LOSS.

 - The iso was simply tested for boot and a couple things checked...

 - The uefi_img is NOT tested at all...

Use it AT YOUR OWN RISK. YOU WERE ADVISED

********************************************************************

---- FOR TESTING PURPOSES ONLY, Due to NOUVEAU Git Changes,LATEST UPDATED BUILDS available here: ----

   https://drive.google.com/folderview?id=0B2evBKvIpdYkYWltaHNKMjV0MHM&usp=sharing

identify:

---------

what build your running: kk-x86-4.4-r2 with Mesa 10.4 (iso / uefi_img)

your system: dell xyz / asus xyz / etc.

issue: wifi / screen / boot / ext4 format / etc. 

provide logcat / dmesg / bugreport logs if possible....

don't know how...use the android-x86 forums and look it up,

many others have done it....

Help the developers help you....

[Ottavio Caruso]

On 29 January 2015 at 17:34, rbg <rbg.hp...@gmail.com> wrote:
> ---- FOR TESTING PURPOSES ONLY, Due to NOUVEAU Git Changes,LATEST UPDATED
> BUILDS available here: ----
>
>
> https://drive.google.com/folderview?id=0B2evBKvIpdYkYWltaHNKMjV0MHM&usp=sharing

What's the "64-bit-Kernel-Build" folder for? Is the whole system
compiled on a x86_64 or just the kernel?

[rbg]

the folder "TESTING-ONLY-UPDATES" is the latest with noveau...

the other two folders are the initial Mesa 10.4 builds, 32bit kernel builds and 64bit kernel with 32bit user space builds...

[rbg]

RENAMED FOLDER:

the folder "UPDATES-TESTING-ONLY" is the latest with noveau...

[Douglas Santillan A.]

It was late and I was reading something related TR1 support for applications, and that was the general go.

I am not positive 100%, but I think that after the LOCAL_MODULE lines in Android.mks​ there should be a

LOCAL_CPPFLAGS := -std=gnu++0x  line or preferably both:

LOCAL_CPPFLAGS := -std=c++0x -std=gnu++0x

[john gully]

Reatek 8723bs is there any reason this cannot be combined into the latest version, I know ppl say I can do it myself but I will be honest, I'm not the sharpest tool in the shed when it comes to this and I can't seem to get  my head around it. It would be much appreciated.

Thanks.

John

On Saturday, January 24, 2015 at 7:20:52 AM UTC+10:30, Chih-Wei Huang wrote:

[Gabriel GOUGUET]

good Morning,

Downloaded and tested on 2 laptop wiith Nvidia Cards
DELL VOSTRO 1510 with a Gforce 8300 work fine, only the wifi don't work because the driver is not compiled by default (broadcom bt4312)
DELL VOSTRO 1320 with a Gforce 9300 all works.

For the moment all is ok, i compile by myself with some modification to integrate the bt43 among others.

this week end i test it on my desktop with a Nvidia GT240.

Good Week-end to all

[Chih-Wei Huang]

2015-01-30 18:28 GMT+08:00 Gabriel GOUGUET <gabriel...@gmail.com>:
> good Morning,
>
> Downloaded and tested on 2 laptop wiith Nvidia Cards
> DELL VOSTRO 1510 with a Gforce 8300 work fine, only the wifi don't work
> because the driver is not compiled by default (broadcom bt4312)
> DELL VOSTRO 1320 with a Gforce 9300 all works.
>
> For the moment all is ok, i compile by myself with some modification to
> integrate the bt43 among others.

Fine. Please provide patches once you test OK.

[Mauro Rossi]

Hi Gabriel, to all people testing,

Did you see temporary artifacts in the background (like strange dotted squares) at Sign In?

Do you have the chance to try OpenGL ES 2.0 apps and collect dmesg, logcat?
Thanks

OpenGL ES 2.0 Demos (Harism) is producing hangs, but sometimes it freeeze/slows things  without hangs or some OpenGL demos are rendered black.
Booting in Debug mode and enabling EGL errors logging can help highlight some OpenGL errors, the output will go in /data/log.txt

[ALT]+[F1]
setprop debug.egl.trace error
[ALT]+[F7]

M.

[Meerio]

are you sure that your module is called bt4312? i've found that it's a bluetooth module , while the BCM4312 is the wifi module! in that case i'm highly interested in your patch, because i've the same issue!

Il giorno venerdì 30 gennaio 2015 11:28:49 UTC+1, Gabriel GOUGUET ha scritto:

[Gabriel GOUGUET]

Yes excuse it's my fault

because one off the driver for the bmc43xx card's is called b43 and technicaly there is no patch, it's just a little boring process :)

on this wiki page you could fine all the explanation and th process to activate YOUR BMCxxxx card , i's the problem 2 kernel drivers and one from broadcom not necessary compatible and firmware files to find in some cases.

https://wiki.archlinux.org/index.php/broadcom_wireless

because technicaly all is in the linux kernel no patch needed !!!

Best regards

[Gabriel GOUGUET]

just tioo give the link to the oficial Broadcom's BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and BCM43228-based hardware driver

http://www.broadcom.com/support/802.11/linux_sta.php

Best Regards

[Gabriel GOUGUET]

actually i'm testing the process of this webpage

http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/#Other_distributions_not_mentioned_above

on this page you have a table with the drivers to use for the BMCxxxx you have.

Best Regards.

the only thing i do it's activate te B43 driver in the default_x86

[Gabriel GOUGUET]

Hi,

For the moment nothing really stange :) i don't to today oen gl test i do it this night, for the moment, i test general stability.

Best reagrds

[rbg]

FWIW:

it can be patched, spend time reading all the available documentation BUT....

I have b43 wifi implemented as I have an older wifi card I test with...I do not add it to builds anymore because if

you look at all the documentation the broardcom driver support is all over the map......

bcrmsmac / bcrmfmac / b43 / b43 legacey / wl, oh and if you use A then blacklist B cause it'll cause issues

and so on and so forth....it's a nightmare.....

chips a/b/c are supported by this b43 group, chips d/e/f are supported by bcrmsmac and so on...

now when someone who has a wifi driver that has ssb uses the build their wifi doesn't work

cause the broadcom driver wasn't blacklisted and uses ssb....

I'm sure the developers would welcome a patch that solves all these issues, and doesn't

cause issues for other wifi users at the same time.....

Ubuntu and other distributions have gone through a lot of work over the years to iron all that out

using blacklist/whitelist and who knows what...and they have done it well....

[Meerio]

i know, i've had this notebook and i had A LOT of problems, even on major distro like ubuntu. if you say that i'll use an external key like how i'm doing now, or i'll change with another. 

thanks rgb and mauro for your amazing work, in the weekend i'll provide logcat with opengl test as pointed!

broadcom sucks

[Gabriel GOUGUET]

the procedure i have put in copy before are FOR LINUX (OpenSuse, ubuntu etc..)

As you discuss about ubuntu

the Official link to activate and configure the B43 driver for Ubuntu it's not really plug and play or automatic

The only difference with the previous link, Ubuntu have allready download the firmware from Broadcom and give a package to install.

http://doc.ubuntu-fr.org/wifi_broadcom_bcm43xx

what i do actually, 

1. i have download the firmware files for B43, put then in device/generic/common/firmware 
   
2. I have activate the 2 drivers from the kernel b43 and brmf...
3. compilation in progress.
4. after i test if it's work and it's stable.
5. if not working try to compil the sta_linux official driver but the probleme 2 differents driver's source for 64 bits and 32 bits 

Best regards.

[rbg]

yes it's a good exercise to go through....

I provided the build in October and some still had issues as I just straight through incorporated it...but

what was needed was the mix and match blacklist/whitelist and a way to implement based on BCM wifi devices

on the users tablet/notebook/desktop machines...........

you can read some of the conversations here...and even try the build...!!!

https://groups.google.com/forum/#!searchin/android-x86/broadcom/android-x86/qzU0G2zz8xE/wyO32ld6nrwJ

[rbg]

and this should be taken up in another thread because this thread needs to help the developers

with the mesa 10.4 intergration which helps us all move forward.....IMO

[rbg]

REPOST: (back on track)

Mauro Rossi

Hi Gabriel, to all people testing, 

Did you see temporary artifacts in the background (like strange dotted squares) at Sign In?

Do you have the chance to try OpenGL ES 2.0 apps and collect dmesg, logcat?
Thanks

OpenGL ES 2.0 Demos (Harism) is producing hangs, but sometimes it freeeze/slows things  without hangs or some OpenGL demos are rendered black.
Booting in Debug mode and enabling EGL errors logging can help highlight some OpenGL errors, the output will go in /data/log.txt

[ALT]+[F1]
setprop debug.egl.trace error
[ALT]+[F7]

M.

[Vaidotas]

When/if video acceleration works, it boots up and works on Lenovo Miix 2 8 tablet. What is interesting, that screen auto-rotation works in this build.

[Meerio]

Hi all!

I've followed Mauro's procedure :

i've setprop debug.egl.trace error 

i've installed the apk and run some demos

several times the system hanged , in the last test i stopped in time

i attach logcat dmesg and dumpsys

My hardware is atom n270, nvidia ion chipset ( with a geforce 940m) 2 gb ram 

I hope that i've done things correctly

[pstglia]

Hi Everybody,

First of, sorry for the very long post  :)

I've performed some tests with my GeForce 210 (hooked on my A10 5800K - switched primary device on bios setup)

I can run some stuff (Complete Antutu test, Mussoumano, Candy Crush Soda) however I experience random freezes (specially on Antutu, when switching tabs after a complete test). It's not a full system hang: I can't move mouse or switch to console, but I can switch numlock on and off, so it indicates systems is performing some heavy action and/or, waiting some return.

In order to get info during this state, I've wrote a very simple script that I run on background before performing any test (data_collector.sh - attached).

It receives 2 args: Sleep interval between collects (in seconds) and a output dir where you want the files be saved on.

In my case, I'm saving stuff on a flash drive (not the same I use to boot Android). I do like this:

1) After entering graphical mode, I connect the flash drive and check were it was mounted (In my case /storage/usb1)

2) I switch to console (ALT+F1) and copy the script to /data dir:

cp /storage/usb1/data_collector.sh /data

3) Add permissions (exec should be enough - but 777 won't hurt) and run it in background:

cd /data

chmod 777 /data/data_collector.sh

./data_collector.sh 30 /storage/usb1 &

4) Switch back to graphical mode (ALT + F7) and perform my tests.

output files are appended with sequence number and current time (ex: dmesg_3_122700.txt)

My logs (specially dmesg outputs) suggests every time nouveau receives any instruction threated as invalid the system hangs.

Ex: I executed Antutu test about 11:49.If we look dmesg got on 11:48:44, no nouveau problems reported on the last lines.

<6>[ 1500.724581] binder: undelivered transaction 247640

<6>[ 1500.724588] binder: undelivered transaction 247648

<6>[ 1500.724594] binder: undelivered transaction 247656

<6>[ 1504.626446] binder: undelivered transaction 249093

<11>[ 1504.677336] init: untracked pid 5058 exited

<11>[ 1504.677398] init: untracked pid 5068 exited

<14>[ 1524.409583] healthd: battery l=0 v=0 t=0.0 h=1 st=1 chg=

<14>[ 1584.439781] healthd: battery l=0 v=0 t=0.0 h=1 st=1 chg=

<14>[ 1644.424045] healthd: battery l=0 v=0 t=0.0 h=1 st=1 chg=

If you look next dmesg output (from 11:49:19) nouveau kernel module returned some errors:

<3>[ 1712.666449] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 6 [tutu.ABenchMark[5527]] get 0x002019bb30 put 0x002019ce04 ib_get 0x00000322 ib_put 0x0000032b state 0x80007698 (err: INVALID_CMD) push 0x00400040

<3>[ 1712.666474] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR INVALID_BITFIELD

<3>[ 1712.666495] nouveau E[  PGRAPH][0000:01:00.0] ch 6 [0x003f9a8000 tutu.ABenchMark[5527]] subc 3 class 0x8597 mthd 0x0208 data 0x00047694

<3>[ 1712.666535] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 6 [tutu.ABenchMark[5527]] get 0x0020375184 put 0x0020375198 ib_get 0x00000323 ib_put 0x0000032b state 0x80000000 (err: INVALID_CMD) push 0x00400040

<3>[ 1712.666560] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR INVALID_ENUM

<3>[ 1712.666575] nouveau E[  PGRAPH][0000:01:00.0] ch 6 [0x003f9a8000 tutu.ABenchMark[5527]] subc 3 class 0x8597 mthd 0x020c data 0x00000600

<3>[ 1712.666603] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 6 [tutu.ABenchMark[5527]] get 0x002019db70 put 0x002019ec78 ib_get 0x00000324 ib_put 0x0000032f state 0x80007458 (err: INVALID_CMD) push 0x00400040

<3>[ 1712.666618] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR INVALID_ENUM

<3>[ 1712.666631] nouveau E[  PGRAPH][0000:01:00.0] ch 6 [0x003f9a8000 tutu.ABenchMark[5527]] subc 3 class 0x8597 mthd 0x1658 data 0x0010731c

<3>[ 1712.682809] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 6 [tutu.ABenchMark[5527]] get 0x00201a202c put 0x00201a3e0c ib_get 0x00000333 ib_put 0x00000334 state 0x80007220 (err: INVALID_CMD) push 0x00400040

<3>[ 1712.699551] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 6 [tutu.ABenchMark[5527]] get 0x00201a6080 put 0x00201a75f8 ib_get 0x00000341 ib_put 0x00000346 state 0x80006ecc (err: INVALID_CMD) push 0x00400040

<3>[ 1712.699586] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 6 [tutu.ABenchMark[5527]] get 0x0020375184 put 0x00203751a4 ib_get 0x00000342 ib_put 0x00000346 state 0x80000000 (err: INVALID_CMD) push 0x00400040

At this point, system is "freezed". Logcat shows Antutu is taking long time to respond:

01-31 11:49:20.149  3926  3959 I InputDispatcher: Window 'Window{21a88e00 u0 com.antutu.ABenchMark/com.antutu.benchmark.activity.MainActivity}' spent 4777.2ms processing the last input event: MotionEvent(deviceId=1, source=0x00002002, action=7, flags=0x00000000, metaState=0x00200000, buttonState=0x00000000, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, displayId=0, pointers=[0: (772.0, 685.5)]), policyFlags=0x42000000

...

01-31 11:49:20.150  3926  3959 I InputDispatcher: Window 'Window{21a88e00 u0 com.antutu.ABenchMark/com.antutu.benchmark.activity.MainActivity}' spent 4417.3ms processing the last input event: MotionEvent(deviceId=1, source=0x00002002, action=7, flags=0x00000000, metaState=0x00200000, buttonState=0x00000000, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, displayId=0, pointers=[0: (771.8, 656.2)]), policyFlags=0x42000002

After about 2 minutes in this state, system recovered itself (restarted SurfaceFlinger) - SysRq also shows lots of info on dmesg

I'd risk myself saying we have some kernel driver issue here. drm_gralloc doesn't submit any CMD to gpu AFAIK: Just inits buffers and map areas and returns a pointer to the component using it. But I can be wrong.

Note: I have a version of drm_gralloc that pushes a lot of cmds to GPU when creating a new device (they were copied from xf86-video-nouveau - see ). However, I have the same issue using it.

Regards,

pstglia