[AT&T Samsung Galaxy S 4 General] Aou:
Well! I think I've found the root of the color and rotation problems, and I don't know how solvable it may be, unfortunately. Here's my train of thought:

- The basic framebuffer driver for Xorg does not work properly with the Adreno 320 that's in I337. It's rather buggy, doesn't load any X window manager properly (most of them just completely crash, others won't work without a proper video card driver) at all these days, and it's pretty much a waste of time pursuing it seems. I might look back into this again after investigating some more options, but only as a last resort. Any sort of acceleration would be impossible using this.

- I've got Freedreno loading mostly pretty well. If combined with Mesa, it seems that 2d and 3d acceleration is likely possible, and it's working with Android's KGSL kernel modules. These are built-in to the Android Kernel, but Freedreno also requires that DRM (and a couple other components) are enabled as well, requiring the custom kernel.

- In order to correct colors, enable rotation, and basically any control at all, Freedreno relies on its own EXA module. Unfortunately, this module works directly with the 2d core of the Adreno 320 (I've tried telling it to just use the 3d core, and this causes the whole phone to crash).

- From what I can tell, the Galaxy S4 (at least the U.S. variants) have the msm8960ab SoC, which is apparently very distinctively different than the msm8960 SoC. I'm guessing this has something to do with the faster, 1.9Ghz clock?

- Check out this bit of code from devices-8960.c:

struct platform_device *msm8960_footswitch[] __initdata = {
FS_8X60(FS_MDP, "vdd",	"mdp.0",	&mdp_fs_data),
FS_8X60(FS_ROT, "vdd",	"msm_rotator.0", &rot_fs_data),
FS_8X60(FS_IJPEG, "vdd",	"msm_gemini.0",	&ijpeg_fs_data),
FS_8X60(FS_VFE, "vdd",	"msm_vfe.0",	&vfe_fs_data),
FS_8X60(FS_VPE, "vdd",	"msm_vpe.0",	&vpe_fs_data),
FS_8X60(FS_GFX3D, "vdd",	"kgsl-3d0.0",	&gfx3d_fs_data),
FS_8X60(FS_GFX2D0, "vdd",	"kgsl-2d0.0",	&gfx2d0_fs_data),
FS_8X60(FS_GFX2D1, "vdd",	"kgsl-2d1.1",	&gfx2d1_fs_data),
FS_8X60(FS_VED, "vdd",	"msm_vidc.0",	&ved_fs_data),
};
unsigned msm8960_num_footswitch __initdata = ARRAY_SIZE(msm8960_footswitch);

struct platform_device *msm8960ab_footswitch[] __initdata = {
FS_8X60(FS_MDP, "vdd",	"mdp.0",	&mdp_fs_data),
FS_8X60(FS_ROT, "vdd",	"msm_rotator.0", &rot_fs_data),
FS_8X60(FS_IJPEG, "vdd",	"msm_gemini.0",	&ijpeg_fs_data),
FS_8X60(FS_VFE, "vdd",	"msm_vfe.0",	&vfe_fs_data),
FS_8X60(FS_VPE, "vdd",	"msm_vpe.0",	&vpe_fs_data),
FS_8X60(FS_GFX3D, "vdd",	"kgsl-3d0.0",	&gfx3d_fs_data_8960ab),
FS_8X60(FS_VED, "vdd",	"msm_vidc.0",	&ved_fs_data_8960ab),
};
unsigned msm8960ab_num_footswitch __initdata = ARRAY_SIZE(msm8960ab_footswitch);

As you can see, the 2D devices are explicitly not enabled on the msm8960ab. This is despite what you can enable/disable in the kernel config.

- The first thing I checked out is: "what's the difference between gfx3d_fs_data_8960 and gfx3d_fs_data_8960

ab

?" ... the answer lies in the same file:

static struct fs_driver_data gfx2d0_fs_data = {
.clks = (struct fs_clk_data[]){
{ .name = "core_clk" },
{ .name = "iface_clk" },
{ 0 }
},
.bus_port0 = MSM_BUS_MASTER_GRAPHICS_2D_CORE0,
};

static struct fs_driver_data gfx2d1_fs_data = {
.clks = (struct fs_clk_data[]){
{ .name = "core_clk" },
{ .name = "iface_clk" },
{ 0 }
},
.bus_port0 = MSM_BUS_MASTER_GRAPHICS_2D_CORE1,
};

static struct fs_driver_data gfx3d_fs_data = {
.clks = (struct fs_clk_data[]){
{ .name = "core_clk", .reset_rate = 27000000 },
{ .name = "iface_clk" },
{ 0 }
},
.bus_port0 = MSM_BUS_MASTER_GRAPHICS_3D,
};

static struct fs_driver_data gfx3d_fs_data_8960ab = {
.clks = (struct fs_clk_data[]){
{ .name = "core_clk", .reset_rate = 27000000 },
{ .name = "iface_clk" },
{ .name = "bus_clk" },
{ 0 }
},
.bus_port0 = MSM_BUS_MASTER_GRAPHICS_3D,
.bus_port1 = MSM_BUS_MASTER_GRAPHICS_3D_PORT1,
};

- It appears that a better name for the msm8960ab is "APQ8064" or "APQ8064T" in some cases. In all the references in the source code that I can find about the APQ8064, there is only mention of the kgsl_3d0. This basically says to me that the kgsl_2d0 device has been completely removed.

Conclusion: Freedreno using KGSL might be impossible on the Galaxy S4 (most variants), at least not without completely re-writing some parts of it. Affected variants:

GT-I9505, SGH-I337, SGH-M919, SCH-I545, SPH-L720, SCH-R970, GT-I9508, and SGH-N045 (according to Wikipedia). This means that 2D/3D acceleration in native linux will need to find another way.

I'll continue to poke around with KGSL more, but without "kgsl_2d0", it seems that Freedreno is not a great option. At least not while relying on KGSL. As a side project, I'm looking into getting the "msm-drm" version working, but this may involve completely replacing or tweaking the Android kernel. Or not. We'll see. My first attempts at this new version resulted in complete phone crashes. :P

So, despite 50+ hours of research and fiddling with this stupid thing, I'll need to take a completely different approach.